What's New in PHP 8.1
stitcher.io
stitcher.io
$array = array_merge(["a" => 0], $array1, $array2);
could be replaced with this: $array = ["a" => 0, ...$array1, ...$array2];
It seems small here, but anything that stops devs from having to nest a bunch of array*() calls in PHP is an excellent change. I don't know how many times I've come across code that does something like this: $array = array_values(array_unique(array_filter(array_merge($one, $two, $three))));I use PHP a fair amount, but this is one area that irks me. PHP arrays can be arrays, lists, and hash maps. PHP obviously copied some of Perl's features, and I never understood why hashmaps and arrays weren't different types, as they are in Perl.
Thanks to their mixed nature they're very versatile. People even make small DSLs out of them. And they're order-preserving, so they won't inject non-determinism just to smugly teach you a lesson about real hash tables.
If a programmer use lists in lisps where vectors or hash tables are more appropriate, he is doing something wrong.
Likewise, simulating arrays in hash tables, which is what PHP expects one to do, is a very bad idea.
Bash lacks multidimensional arrays, but it does have hash tables, so some programmers resort to simulating multidimensional arrays by using keys such as `"3,4"` as a string in hash tables, this would be a very bad idea if Bash had true multidimensional arrays. In it's lack thereof, it is only a bad idea where no better idea is possible.
If you do need to deal with data structures that are quite large (i.e., take GBs of memory), perhaps PHP is not the right language.
This is the TXR Lisp interactive listener of TXR 249.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
Poke a few holes in TXR with a fork before heating in the microwave.
1> [mapcar succ "abc"]
"bcd"
2> (car "abc")
#\a
3> (cdr "abc")
"bc"
4> (cadr "abc")
#\b
5> (cddr "abc")
"c"
6> (cdddr "abc")
nil
7> (rplaca (copy "abc") #\x)
"xbc"
8> (rplacd (copy "abc") "yz")
"ayz"
9> (ldiff "abcd" "cd")
"ab"It also makes some potential niceties impossible. Python can give a special meaning to a negative index into a list, because it can never truly exist, but PHP has to treat it like a key and do a normal lookup.
In fact, they're getting slower in real practice. (We've been trading off speed for safety and power consumption for years now.)
Of course there is Ds\Sequence, but having it as a part of some relatively obscure library isn't the same as having it as a part of a language, with syntax as simple as [1,2,3]. Actually, I'm not even sure: does it have as good performance, as "arrays" do? I never tested.
(I was involved in the development of this function: https://github.com/php/php-src/pull/4886)
As far as PHP is concerned, a list is a subset of arrays where the keys are ordered integers starting at zero. Any array that doesn't fit this pattern could be considered a "map" -- there's no middle ground.
Name your vars $some_list for integer arrays and $some_hashmap (sometimes $some_coll (collection)).
I'm 1/2 joking. I maintain loads of legacy and recent PHP LOB apps. Var-name fixes can do a lot to help the case in any loosely typed langs (I learned the trick from VB4.0)
No need for fancy Amazon Web Shmervices, no need for Jamstack jumping through the hoops.
Just find any host that supports PHP, upload your file, and done.
"Jamstack" sites, in their simple form, or even combined with a modest number of lambda functions, can be deployed to github pages / netlify / vercel and a number of other platforms for free. Push a commit to github, get an automatic deployment going, boom, done. I am not aware of any analogues in the php ecosystem.
For JAMStack, just git push and done. I don't see PHP is easier ;)
With PHP you can just drop it anywhere in the htdocs and done.
Don’t get me started on concurrency either...
PHP solves concurrency very well - it just passes the problem to the web server.
If you need multithreading to service a http request then you are either doing something wrong, or over-engineering the problem. Other language platforms also service requests in a single thread, including Node.
Contrast that with going up one major version in Scala where all I need to do is fix the compile errors and then I’m confident it won’t surprise me with runtime errors.
This is a stupid solution to a stupid problem. Defaulting to weak typing has enough problems, but changing the behavior of your data structure based on its contents is next-level pain. I used PHP for a few years at a student dev job and I can’t count how many times this conflation wasted my time and introduced various bugs.
If PHP wants to become more respectable as a PL, it has got to break that out into real arrays (a linked list might be acceptable under certain circumstances) and maps.
PHP does no such thing. There is one array type with one behaviour. There is no distinction between different kinds of arrays in the language.
$ php -r 'var_dump([1, 2, 3, 4]);'
array(4) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
[3]=>
int(4)
}
$ php -r 'var_dump(array_filter([1, 2, 3, 4], function ($x){return (bool)($x % 2);}));'
array(2) {
[0]=>
int(1)
[2]=>
int(3)
}
$ php -r 'var_dump(array_map("strval", array_filter([1, 2, 3, 4], function ($x){return (bool)($x % 2);})));'
array(2) {
[0]=>
string(1) "1"
[2]=>
string(1) "3"
}Oh boy... That ship has sailed a long time ago...
It doesn't make it a stupid solution or a stupid problem.
If you validate and conform your types at program edges it's rare you ever really need to do type checking.
That is, a properly structured PHP application has all the benefits of dynamic typing and few of the problems that static type checking supposedly eliminates.
I like both static and dynamically typed languages.
Just like I like Async and non Async languages.
All language types require practice and learning to adjust to the different patterns that are required.
If you write PHP like JavaScript, or if you write PHP like java, or php like C++, you're going to have these problems.
If you write PHP like PHP, function heavy, class light, and a mix of functional and procedural depending on context it actually works out very well for a lot of things.
But go ahead, call the language stupid and irrespectable.
Could you give examples of this? I'm of the opinion PHP could use more strictly typed arrays/lists, but I haven't run into any issues with PHP arrays myself.
So if you have eg a hashmap of [naughty_word => replacement], then [“penis”=>”willy”] and [“asshole”=>”bottom”] work fine, but [“69”=>”cuddle”] crashes your program with an "unexpected integer” exception.
edit: itchy trigger finger
Enum is basically a bunch of constants, for all practical purposes. There were enums in Java for a long time, long before languages with more-or-less proper type systems became mainstream, and everybody was fine with a rigid mess of type system Java has.
So, to have what effectively is enum in PHP, I do just
class Status
{
const STATUS_A = 'STATUS_A';
const STATUS_B = 'STATUS_B';
// and so on
{
So it looks like a new enum would be basically just a syntactic sugar for that. (And finally a way to make a type hint for $a = Status::STATUS_A.)Were we? Java is literally the language that drove me to hate types and prefer python for a few years, until I learned Haskell..
Offline typecheckers (not included with PHP) can analyze the control flow to prove that any invalid types have been ruled out when an operation happens. It's not nearly as principled as proper sum types, but it works alright in practice.
PHP's upcoming enums are simple values, more like C's enums than Rust's enums.
[0]: https://www.php.net/manual/en/language.types.declarations.ph...
Sum types are, in effect, a small domain of dynamic typing.
If people are so gung ho on adding in syntax hacks, shortcuts, etc, they seem to be bringing ideas from other languages and why not simply continue to use that other language? PHP seems to be looking more and more like Go or JS to me now. Anyone want to start a fork called “PHP Classic”? :)
No one is forced to use the new syntax, it's just different tools in the tool belt.
I tried Visual Studio years ago, didn't care for it.
What finally convinced me is the Go package system. I like that Go has a builtin package manager, while I dont think PHP does. I know about Composer, I just wonder. After all these years, why hasnt PHP incorporated a builtin package manager?
Congrats on getting a package manager for Go!
So let me ask, what problem does composer have that you hope to see a builtin package manager solve (at the cost of losing its own dedicated team) ?
- dev recruitment is hard.
- dev retention is hard.
- hard to find people that write clean, modern, performant PHP
- it is PHP, with everything that it entails. It does not enjoy the best reputation as a language.
Number of available developers is still high but it could be even higher if it had the same successful propaganda as JavaScript or Python.
There is nothing in the language itself that should stop it from competing with any general purpose language, not anymore.
I think this is the next important step for PHP, have charismatic & humorous evangelist like Douglas Crockford.
Crockford’s missionary work was done during a time when JavaScript was in a big expansion because everyone wanted to write single page applications.
But today there is huge JavaScript fatigue and more and more developers have start to realize that server side rendering is (back to) the future for most of the traditional web, especially in a time where time to market has become even more important.
The constant churn of the JavaScript realm have now reached epidemic levels, a massive & relentless wave of deprecated and unsupported projects sweeps over every organization. Somewhere right now some poor developer inherits a Angular 1.1 project built with gulp.
I think also there have been a shift in regards to fullstack developers versus frontend & backend developers, many companies have woken up to disastrous idea of splitting frontend & backend developers into separate teams and now merging them again, as result the fullstack developer becomes more important. PHP is in my opinion best fullstack web platform you can use.
Say after me, No more build steps for rendering a paragraph, no more unhandled Ajax errors, no more REST JSON apis with only the frontend as consumer, no more reimplementing the database schema in JavaScript, no more asynchronous state rendering on the same page. <Insert Braveheart meme>
> Somewhere right now some poor developer inherits a Angular 1.1 project built with gulp.
That hit hard. I was reassigned to an old project from 5 years ago with an archaic framework, to refactor all the code to the "new shinny JS framework". Ironically, I was in the team that built it 5 years ago. It is dreadful. Rinse and repeat.
I feel like I'm doing something wrong when I advocate against projects that need 50,000 files and a 2-minute build when you could just do with HTML/CSS, native JavaScript and a simple CRUD backend.
Dynamically update parts of your page but still render everything on the backend, where you already have all your data.
Pass HTML fragments back, like we did in the old days prior to the JSON hype, but let htmx do the fetch & swap work so you don’t have to, that is only repetitive anyways.
Now you hardly need jQuery (or similar) anymore either, Just HTML & CSS.
If you use structured projects, (symfony) in our case its much easier to use and maintain.
We have older Java and Perl and Python to maintain. Its much harder to get those up and running.
The startup I worked at 8 years ago used PHP and got bought. I think the ability to get into it quickly and get something running is underrated frankly.
Some of those problems got addressed but by the time that happened PHP's reputation was irreversibly trashed and now nobody wants to know about it.
That is the world we live in. People do not want to learn PHP or work in PHP. Do a survey on any higher education institution and verify it yourself.
All the features you feel proud about... go take a look at the Java VM, .NET VM or a JS VM like V8... Those VMs are much more powerful than the PHP interpreter will ever be. Even CPython is faster.
Plus, as a Java developer you can make more than a PHP developer and there are more types of development you can do. Mobile, backend, desktop. PHP is mostly limited to backend and it is not even the best solution for that.
I haven't run the tests myself in 2021, but I used to do PHP for many years, and there were significant performance improvements done in PHP which I remember took it way ahead of Python at the time.
The benchmarks I’m familiar with[1] show recent PHP releases to be a lot faster than CPython for many tasks. Are there better benchmarks I should be aware of?
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
The majority of new programmers might not want to, but I consider it a clever strategy for new devs to get their foot in the door with their first real job. There's always a huge amount of open PHP jobs and if more elite devs are passing over those jobs then it means an opportunity for somebody. And some of those people who start with PHP will move on to more modern or better languages after they get their legs. It's a smart path to get on the dev career track, especially if you don't come from a traditional CS or dev background.
It's like building a car designed for just one thing, to go very fast on straight roads, then a general-purpose car comes along and somehow beats this car in this category.
How did it lose its grip? Did the PHP Group become too complacent being at the top?
Most general purpose languages do not have built in templating and do not have templating in their standard library.
As a programming language, many modern languages have a faster and more optimized runtime than PHP. If the Laravel authors ported their framework to Node, Python or Java it would certainly run faster.
As a templating language, it has to run on the server. That means you pay for the computing cost of templating not the end user. Unless you do your templating using a JS solution.
On top of that, you have to transfer a rendered page from your application server instead of just serving files from CDN at a fraction of the cost.
Overall, PHP is the wrong solution for the wrong problem. I used PHP in 2004 and then moved on. The industry at a large also moved on.
No way. It is pretty easy. To be fair it is harder in the Bay Area than let's say Europe, but it is still a non-issue. Also, the language is extremely easy to pick up, everyone is able to understand the code. This week for example I 've had an ios dev that is using Obj-C/Swift just dig into the code themselves to get clarity on an endpoint's execution.
> dev retention is hard.
Never really had an issue there.
> hard to find people that write clean, modern, performant PHP
This also has not been a problem in the past few years. For context, I 've had multiple devs excited and pushing to start using new PHP8 features, already (and I had to be the boring one and ask to wait for hotfixes, a version .1 or .2 and see how stable and secure 8.x is first).
> It does not enjoy the best reputation as a language.
This is true. I 've met people who refuse to even look at PHP code, even though they are paid to do so (they might even refuse at the detriment of their peers). I 've never seen a "this is beneath me" attitude with any other tool or language before. (except perhaps the hate SQL databases got in 2015-2016) So yeah, the hate runs deep.
I have been contacted for every single of my other skills, even F# which is one of the most rarely used languages ever.
Many PHP projects are successful. WordPress, Nextcloud, Wikipedia, Facebook...
Something about it must be right.
What does PHP entail??
And those languages are pretty popular compared to others.
The programming language you use is a important factor when it comes to scaling your team (and your product, and your business).
I do not want to start a bikeshedding holy war. The reference implementation of PHP is pretty inferior to that of other scripting languages such as Ruby, Python, Julia and Node. There are other implementations that are better but come at a compatibility cost.