The folks over at Kinsta.com have put together some end of the year usage statistics for PHP across the web trying to answer the "is PHP dead?" question.

You’ve probably heard about how the new WordPress Gutenberg editor brings block-based editing to WordPress.

There is a change going on behind the scenes that casual users might not notice, that Gutenberg blocks are made using JavaScript (React, JSX, and ES6), not PHP. That change, along with other shifts in web development, might have you wondering, “is PHP dead?”.

People have been calling for the death of PHP for years now (you can find “Is PHP Dead?” posts as far back as 2011). And yet, PHP still persists… In this post, we’ll dig into the data and show how PHP isn’t close to being dead (even if you really wish it were).

The article talks about how, despite PHP not being the "most modern programming language", it's still in use by almost 80% of the websites on the internet (8 out of 10 sites). While the number is declining slightly, it's still large chunk of the web based on the reporting from the X-Powered-By header. They also point out that PHP is faster and better than ever with new, impressive features being added constantly and new versions being regularly released.

They also note that it's easy to find PHP developers (with actual experience) and, while you don't have to like PHP, it's definitely far from being dead.

The Exakat service has posted their latest "PHP Index of Coding" for August 2018. In this index, they share statistics from the projects the service has analyzed and some trends based on the results.

Every month, Exakat runs thousands of analysis on half a million lines of PHP code. This is primarily for testing purpose, a kind of torture test that checks the engine run on any kind of code. And it is very useful to ensure all situations are correctly handled.

We also extracted the following stats out of 1700+ projects, analysis by analysis. This way, any issue may be ranked from ‘wide spread’ to ‘very unusual’. In fact, ‘wide spread’ may also be understood as : ‘almost a feature’. May be we can suggest a few of them to wiki.php.net.

They include both the latest results and how they compare from the previous entries from May 2018. Analysis points include things like:

• Used Once Variables (In Scope)
• PHP Keywords As Names
• Property Used In One Method Only
• Unitialized Properties
• Should Make Ternary
• Use Named Boolean In Argument Definition
• Assigned Twice
• Locally Unused Property

...and many more. Some of the changes from May are pretty dramatic but others have stayed about the same. Check out the full post for the overview and links to more information about each of the checks.

On the Exakat blog there's a new post covering some of the impact that PHP versions have on codebases they've reviewed in the normal course of their product's analysis and the requirements of Open Source software.

With the upcoming PHP 7.3, the question of the next migration is back on our tables. We’ll hear a strange mix of begging to move to the new versions for features and security, mixed with a constant threatening that some old versions will soon be unmaintained or worse. Indeed, there is versions impact on PHP code bases.

Particular witnesses of that evolution are open source projects. They usually have to support a wide range of versions, and in the same time, are actively encouraged to use the newest features. It is a delicate work of balancing compatibility and progress.

To observe the way Open Source projects handle the evolution of PHP, we have audited 1977 Open source PHP projects, by linting them with PHP versions from 5.5 to 7.3. This taught us the impact of PHP on code, over a long period of coding. Let’s review them.

The post starts by talking about linting of PHP files (checking the syntax for issues but not executing the contents). It then shares some statistics about the number of Open Source projects that lint on every build and how it has trended over time. They also share some results on the age of packages that are in wide use, showing that the ration of "old code" to "young code" is surprisingly similar.

Jason McCreary, creator of the Laravel Shift service that makes it easier to upgrade your Laravel code to new versions, has a new post to his site where he shares Laravel "by the numbers", some statistics based on the use of the service.

I had the privilege to speak at Laracon again this year. The last Laracon talk I gave, Practicing YAGNI, is one I am most proud of. Initially, I wanted to do a continuation on this topic. But there were some other talks on related topics. So I thought, “what can I talk about that’s unique to me”.

The answer was Laravel Shift. As the creator of Shift I have a unique insight into Laravel apps.

I’m super sensitive about sounding salesy. I don’t want to talk about Shift itself. I want to talk about the data derived from Shift.

The statistics are based on around 8500 Laravel applications currently using the service. He shares the results for:

• Most popular Laravel version
• Most popular packages
• Most changed file(s)
• Custom namespacing

Along with these basic numbers, he also shares information about project structures, inheritance injection, facade "abuse", queries in views (using models) and many others. Check out the full post for details on these and other results.

In a new post Larry Garfield suggests and interesting approach to arrays in PHP: stop using associative arrays (or at least "basically never").

The other day I was working on some sample code to test out an idea that involved an object with an internal nested array. This is a pretty common pattern in PHP: You have some simple one-off internal data structure so you make an informal struct using PHP associative arrays. Maybe you document it in a docblock, or maybe you're a lazy jerk and you don't. (Fight me!) But really, who bothers with defining a class for something that simple?

But that got me wondering, is that common pattern really, you know, good? Are objects actually more expensive or harder to work with than arrays? Or, more to the point, is that true today on PHP 7 given all the optimizations that have happened over the years compared with the bad old days of PHP 4?

So like any good scientist I decided to test it: What I found will shock you!

He starts by describing his test environment (a local environment, not a cloud one) and the code for his baseline tests. The code generates an array of one million items where each item is an associative array of an integer/string combo. He wants to see what kind of memory consumption is involved in the creation and processing of this data set via sorting. His second test evaluated the serialization size (again, code provided) again checking the memory consumption. He shares the results of these tests and then moves on to similar tests on:

• stdClass instances
• objects with public properties
• objects with private properties
• anonymous classes

The post ends with a summary showing the results of all tests side-by-side with some interesting results (but you'll have to check out the post for yourself if you want to see those).

Jordi Boggiano, lead developer on the Composer project, has posted another of his PHP version statistics posts, this time for the first part of 2018.

It's stats o'clock! See 2014, 2015, 2016.1, 2016.2, 2017.2 for previous similar posts.

A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. I look in the <a href="https://packagist.org/>packagist.org logs of the last month for Composer installs done by someone. Composer sends the PHP version it is running with in its User-Agent header, so I can use that to see which PHP versions people are using Composer with.

The remainder of the post shares some of the results and differences since November 2017. Among the highlights are:

• The use of PHP 7.2 has increased by a large percent
• The use of all over versions (including PHP 7.1) is dropping
• There is still a large number of packages that only require a version in the PHP 5.x range to be installed

Check out the full post for the complete stats on versions in use and trends (along with some nice graphs of the results).

In a new post to the Exakat blog they try to answer the question "how many parameters is too many" when it comes to the structure of the methods and functions in your application.

Now, that is a classic question, that is often a minefield for anyone writing an increasing long list of argument in a method, or simply trying to set up auditing tools.

Obviously, the answer is not immediate. Parameters may be needed, but on the other hands, currying functions allows to reduce the amount of parameter to one for every function. In between, probably exists a reasonable level that is a golden rule, and also very elusive. So, we decided to check the current practice in PHP code.

They started the research with some of PHP's own native functions that took in specific arguments, ignoring those that took an arbitrary number. Next they made a survey of 1900 open source projects to determine the common practice for parameters by function. The results showed that methods without at least one parameter were "less useful" and that a seemingly reasonable amount of parameters is 5. The post finishes with a spotlight of two they found during their research that had the most parameters: a generated class for database interaction and a dependency injection class.

Jordi Boggiano is back with the latest round of his PHP version statistics as gathered from the information provided by the Composer package management tool for PHP.

It's stats o'clock! See 2014, 2015, 2016.1, 2016.2 and 2017.1 for previous similar posts.

A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. I look in the packagist.org logs of the last month for Composer installs done by someone. Composer sends the PHP version it is running with in its User-Agent header, so I can use that to see which PHP versions people are using Composer with.

He then shares the results of the statistics including the total number of users for each version of the language and the difference in just the last 6-7 months. PHP 7.1 has pulled out as a front-runner with PHP 7.0 coming in closely after. He also shows some historical data showing the decline of the 5.x versions and the rise of 7.x versions over the past years. The post ends with information about the percentage of requirements in packages with 5.6 taking the lead but not by much.

On the Laravel News site there's a new tutorial posted showing you how to integrate your Laravel application with StatsD for statistics gathering. StatsD is a project from Etsy that runs as a Node.js platform and listens for incoming connections providing statistics to record to the system.

I want to show you some tools and techniques you can use to measure anything and everything that you want in your Laravel applications with StatsD. These ideas are simple and not new; yet, I believe that the simplicity and power are what makes StatsD great.

You can also take the ideas in this article and apply them to any programming language or stack. Instrumenting your code can have a huge payoff as your application scales and can help you gain deep insights.

The post starts off by talking about how integrating new features like this should be as painless as possible and some about what StatsD provides. It then talks about "instrumentation" of your code and how metrics can provide insight into what your code is doing and how well it does it. It shows you how to set up the Graphite/StatsD Docker container and how to install the league/statsd package to help make the connection to the server. The post wraps up with some examples of statistics you might want to measure and the code to increment/decrement values in both normal code and middleware (including controller execution time).

On the StackOverflow blog there's an interesting post that looks at the differences in programming languages between countries based on their current state, either a developing country or a wealthy one (or somewhere in between).

Here at Stack Overflow, we’re interested in using our data to share insights about the worldwide software development community. [...] This leads us to wonder how else programming technologies may differ between rich and poor countries, and how that affects our picture of the global software development industry. In this post, we’ll explore these differences, and show that’s it’s useful to segment the software development industry into high-income countries and the rest of the world.

All the analyses explored here were performed on 2017 so far (January-August), on the 250 tags that had the most traffic during that time.

They investigated some of the major programming languages and platforms (including PHP) and found some interesting negative and positive correlation results. The post then covers how they split the list of countries in two (wealthy vs developing) and show results of the technologies they use. They include graphs for each of the points they make and link over to their StackOverflow Insights site where you can gather statistics for evaluation of your own.