Array unpacking is going to help make a lot of coding situations more concise. There isn't a direct comparison in the article, but from what I understand, something like this:
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:
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.
I love them. Lisp can use lists for everything, and PHP arrays ;)
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.
Almost anything can be simulated in any other data type, often with poor performance and easy bugs.
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.
The reality of most of programming I've done is that in 98% of cases you deal with data structures that are sufficiently small for performance not to matter much on modern hardware.
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.
The problem is that lisp APIs tend to treat paired sequences as equal citizens, whereas PHP treats paired arrays as a special case and they're effectively a different data type. This is the same problem with how Erlang/BEAM languages treat strings as a list of character data. It's the same until it's not, and then it's decidedly not.
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"
Funny. I almost dislike all of PHP but think that their choice of basic data structure is the one good thing. Computers are getting faster and faster and simplifying programming could be done to a whole new level. Clojure for example has a similar approach. Okay, PHP lacks contracts, but maybe PHP adds them in 20 years when the mainstream understands that they are great.
For me it didn't really simplify programming, it just added mental overhead. Every array I used was either strictly sequential or strictly a mapping, and the language did nothing to help me keep track of that.
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.
Clojure's persistent collection types include List, Vector, Map, Set and you have namespaced keywords. In general, I don't see how you can compare the approach of Rich Hickey and Clojure to PHP to be honest...
I too dislike PHP, but this is one of the things I hate the most: this is like conflating addition and multiplication of types. Arrays and maps have separate use cases and very different trade-offs and PHP gives you no choice in the matter.
The SPL data structures are widely considered a mistake. They're awkwardly designed, cannot be type-hinted, and often perform worse than pure-PHP alternatives.
I'm kinda used to PHP "arrays", but I really wish it had proper lists. This array_is_list function doesn't change things much: I already have the same implemented in many of my projects. The point is that I shouldn't do that: I just should use a typehint the same way as I'd do it with array or MyCustomClass.
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.
What `array_is_list()` changes is that it makes this check fast. Previously, the fastest method of checking for a list-like array was `$arr == array_values($arr)`, which was slow on large lists and could fail entirely on some unusual structures containing circular references.
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.
Yes a million times this. This becomes a even bigger problem with json_encode when PHP can't tell the difference between an object and array sometimes and outputs the wrong type. Yes you can use stdClass but that feels like such a hack. It would have been amazing if they were different types all along.
I haven't used PHP with regularity since the start of 7.0, but I agree. Having this mushy collection type seems so easy to just replace with [] for arrays/lists and {} for objects/class instantiations by convention.
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)
"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.
You dont need to sign up to multiple sites and maintain multiple accounts. You don't even need to use Git or lambda functions. That's what I mean by jumping through hoops. With PHP I just upload the file and done. Nothing beats this simplicity. For simple stuff, it's my favorite.
Shared hostings might offer Python, but it’s probably neglected (outdated, missing database connection libraries, etc.) and nobody really uses that. Effectively all Python web development is done using WSGI frameworks (or more recently, ASGI), and those frameworks expect to be in long-running processes, usually behind a reverse-proxy. Starting up the Django dev server takes about one second on a blank site, and it increases with code size. The `cgi` module exists, but it’s badly designed, mostly forgotten, and there were plans to remove it (PEP 594).
It is a problem to maintain. Simple example: how do you remove sessions in a multi server environment? Well, you can set a config to do that at random which imposes a cost for that particular request. Or you can run a corn job. This is not a decision in most other scripting languages.
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.
It’s easy to maintain if you don’t change versions. If you upgrade, have fun finding all the pages throwing new warnings.
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.
I agree with your core point, but the comparison to JAMStack is misguided. Push to GitHub, sign in to Netlify (or one of countless similar services), pick the repo to deploy, and you’re done.
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.
Doch. Try piping the result of array_filter to array_map sometime. You can’t do it without an intermediate call to array_values first because the result of passing a list to array_filter does not behave like a list anymore: it operates strictly like a map and cannot have map called on it. (Oh the irony!)
The caveat I'm aware of with array_filter is that it can leave gaps in the indexes, but having an array like that doesn't break array_map. The output from it will just have the same index gap as the input.
Dynamic typing is a trade off, one that requires some explicit type checking in some situations.
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.
I like dynamic typing: most of my work is done in untyped Racket or Elixir. Weak typing is fun, but can be frustrating. My issue is that this single data structure functions like a list in some cases, and a map in others. Try piping the result of array_filter to array_map sometime. You can’t do it without an intermediate call to array_values first because the result of passing a list to array_filter does not behave like a list anymore: it operates strictly like a map and cannot have map called on it. (Oh the irony!)
> I can’t count how many times this conflation wasted my time and introduced various bugs
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.
The one that annoyed me recently - numeric-looking string keys are turned into numeric keys.
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.
What is the idiomatic way to have data in an enum in PHP, aka sum types? Sum types in languages like Rust or Haskell or OCaml can have data associated with them. You'll get an error before runtime if you assume a field is available when it isn't.
This isn't exactly a sum type. Sum type is basically a Union, a proper algebraic data type, and PHP doesn't have algebraic data types (although, even before type hints it was a relatively common practice to "implement" them via PhpDoc... horrible, I know).
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.)
That would probably be union types[0] (or plain old dynamic typing) with checks like `is_null($val)` and `$val instanceof Type`.
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.
This is really making what used to be an easy to read, easy to learn language a lot less of that. Some of us still don’t use IDEs and are okay with more thoroughly defined code that is readable.
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”? :)
I just use emacs. It has enough capability to be an IDE, but I don't use it like that. I use it as an editor, maybe with a language mode to do syntax highlighting and help with formatting.
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?
PHP developers have been very successfully using Composer for many years. It's actually quite nice having the package management decoupled from the language, there's fewer chances for breaking things between upgrades which helps slightly with long term support.
Who knows, maybe one day Composer will be bundled with PHP. (And bundling Composer with PHP wouldn't necessarily mean that Composer would lose its own independent dev team.)
I am not a developer, but I use PHP a lot for scripting and personal automation including small web apps with SQL backend. I found PHP 7 to be a great improvement over 5.x, but with 8 I skipped every single new thing they brought. I can use PHP 8.1 in PHP 7.4 compatibility mode, but I find the features in 8.1 making the language less readable and less logic; for example, 3 dots become part of the language syntax? What is next, emojis as operators? Secret gang hand shakes as functions?
It is true that PHP has a bad reputation and that effectively limits number of potential skilled developers.
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.
PHP is incredibly easy for any competent programmer to pick up.
If you know C/Java you can get into php pretty easily.
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.
PHP was the most competitive when ASP was around. After that, PHP entered a dark age where almost every other language ran circles around it in terms of performance, security, maintainability, tool support... and literally everything.
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?
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 sounds like a sad story. PHP's specialization is in rendering dynamic web pages. It was its ONLY purpose (ignoring niche projects like GTK bindings, etc). And yet even against general purpose languages/VM's (where using it for backend web is a choice, not its only purpose), PHP could not remain competent in its own class.
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.
Dev recruitment is hard to find php developers? wtf are you smoking? I think a lot of this is highly dependent on where you are. My guess is you mostly deal with non php languages?
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 think the OP has a fair point. I could be way off but I feel few developer get excited about working on PHP projects. I jumped ship to Node.js around PHP 5 and haven't enjoyed working on PHP code bases ever since. I think this in part could be due to TypeScript, giving much more confidence in refactoring and moving a project forward. The massive npm module ecosystem is probably also a major factor.
The fact that WordPress and Facebook use PHP is more historic then being exemplary for it being an excellent solution.
Erlang, Haskell and OCaml are excelent languages. But good luck assembling a team that can use those languages. e.g.: 30 developers in 1 year.
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.
I don't agree with this. I'm not going to get into a holy war, but I soundly disagree that it's inferior. Any C/C++/Java programmer can become productive with php very rapidly. The callstacks are familiar to programmers, the language continues to get faster & faster as older legacy structures are replaced with smarter data-structures allowing for JIT optimizations.
