At the beginning of the year, we met with Tomas Votruba who is a well known figure in the European community of PHP developers. We had a nice chat about what trends we can expect in PHP this year, and you can read about it in the interview below.
Hello Tomas, how are you doing? How was the last year for you?
2018 was full of changes for me — I went to Asia for a month all by myself and founded an education company. Now I’m learning how to work accountant and hiring coworkers. I’ve got a lot to learn.
Language isn’t something you can switch in a decade. PHP is popular thanks to long-lasting projects like WordPress (since 2003) and Drupal (since 2001) and thanks to the cooperative community that takes care of the PHP code itself. That’s very rare in programming languages — most of them are owned by commercial companies or they exists without any organization around them.
PHP is used by 78.9% of all the websites whose server-side programming language we know.
To this day, 78.9 % of all websites in the world run on PHP. That’s a lot, right? 2 years ago when we founded the Czech PHP Community Péhápkaři we put that number there as well — it was 83 %. 5 % decrease in 3 years.
It’s up to the community what will happen next and how will the trend continue. Still, I think these numbers are not as important as much as how much you enjoy the coding and community around the language. And I really do love the PHP community for its freedom, mature stability, and predictability that allows you to plan years ahead. But it’s still dynamic enough to develop new features like typed properties in the upcoming PHP 7.4.
In the last 2 years trends like static analysis, Dockerization, continuous delivery, etc. were visible. What do you think would be popular this year?
Dockerization is needed for a specific reason. There is too much diversity. One programmer has Windows with PHP 5.6, the other has PHP 7.1 but misses extensions. It’s just a band-aid to chaos. So is the monorepo approach to companies that have to maintain dozens of repositories.
Static analysis helps you navigate through legacy code. We have more information about code than ever before, but the code is still there and we’ll have to clean it eventually. 2018 was globally and universally about spotting and isolating problems. This year will be about actually solving problems.
How? With Abstract Syntax Tree (AST) and embodied knowledge. These will eventually lead to a faster evolution of the PHP code itself.
Let’s start with AST (Abstract Syntax Tree) — what is it all about?
AST is a way to see the code and to get information about it. More common are tokens and reflection. AST is like these 2 combined on steroids. If you’re into the history of these 3 in PHP, this posts sums it up.
So what is AST? Imagine a 2-floor house. You can see the house from the front, how it looks — that’s code we see in the IDE. Do you need to know how many rooms there or where the electric cables are on the walls? Then you’ll need to look at the blueprints — that’s AST.
Now you have a huge PHP application. You can look at one file, read the class name, the method. Do you want to know what controllers there are, what arguments they use? You’ll take the AST. You know the type of every property, every method, every variable.
That’s the intel we already have with PHPStan, but there is more. As your house gets older, wooden windows are not good enough and it’s chilly inside — you have to pay much more for heating than your neighbors. Do you want to change them to plastic ones with better isolation? Well, you can do it one by one, as a programmer would refactor your code from PHP 5.6 to PHP 7.3 one class by one.
Or you can use AST to do it instantly everywhere — it doesn’t matter if it’s 1 window or 1000 windows. The bigger your house (project), the better.
This is nothing new. The core package used for static analysis tools php-parser has supported this since 2012. It’s only getting trendy now and the community is well educated enough about AST to use it for themselves.
And the “Embodied Knowledge” term? Is this something connected to the developer’s work methodology?
Let’s try another metaphor. Have you ever put together furniture in your home? And have you tried IKEA furniture? It’s amazing how you can build a big wardrobe or bed, and barely touch the manual. That’s embodied knowledge. You don’t have to study at school to build your own furniture. The furniture is built in a way that’s easy to understand.
Same goes with code. When you write code that is self-explanatory, simple, and intuitive, you can delete your documentation because the junior developer will have no problems understanding it. It takes a lot of psychology, asking people for feedback and accepting it (these are 2 different things).
The knowledge is in the code. One step any company can integrate all of their conventions into the CI. Instead of 5 pages about your architecture, you have 15 sniffs/fixers in your CI.
I used this approach in Lekarna.cz in 2015 as an experiment. I setup the architecture with a single goal — to make the developer’s life easier in every possible way. If there was something 2x in the code review, I put it into sniff/fixer and CI took care of it for the rest of our lives. If I had to post links to posts to explain it, it was too complicated.
Soon my team joined Tomáš Pilař. In just 2 months he was already programming without any issues. When I asked him how long he had been working with Nette and Doctrine, he just said: “I barely did use Doctrine before, but it’s pretty clear from the code”. We’re still friends and stay in touch. 🙂
Programmers shouldn’t need to read a manual to understand your code, they should understand it by reading it. If that’s not that case, it’s the fault of the author of the code, not the reader.
And what about the PHP core code boost you also mentioned as a trend on Reddit? What does this mean?
Last year I was picked to speak at PHP.Asia. The talks were great, but the highlight of the whole conference was a panel discussion with 3 men who have been around long enough they might as well be considered the “godfathers of PHP”. Rasmus Lerdorf (PHP founder), Sebastian Bergman (PHPUnit) and Derick Rethans (xDebug).
It started with a fun Q&A (Rasmus would be definitely good late night talk show host), but then the topic quickly led to the history of PHP and why the API is too confusing. One method is called strpos, the second is is_string, and the third is substr. PHP: a fractal of bad design has more examples. Rasmus explained that PHP code is full of inconsistencies for a single reason — to keep it as back -compatible as possible. I think Rasmus is a very practical person and he cares about usability, since upgrading a PHP project is a relatively easy process with fewer BC breaks.
But this comes at a cost: inconsistent naming, that you have to memorize. That’s why there is a place for helper packages like Nette\Strings, voku/portable-utf8, etc., that try to make these methods easier to remember, or thecodingmachine/safe that covers inconsistent return values.
AST solves this in the same way it was able to change 1000 windows for a modern one. Let’s say you rename strposto string_positionin PHP core and drop the strpos function. This would break 78.9 % of all websites the PHP runs on.
Even if the PHP community decided unanimously to do make move, you have to keep the old name for back-compatibility. But with AST, you don’t have to care about back-compatibility breaks. Just say “AST, rename all functions strpos to string_position”. Imagine this as part of a composer update. So, your code will look as modern as it was written in <current year>.
Shameless plug: I work on an open-sourced tool called Rector, where such a change is simply a matter of 1 yaml config. But I know there is much more room for startups to make use of AST then we can imagine.
And what do you think about the rising popularity of frameworks like Symfony on top of projects like Shopsys Framework or Laravel are built?
When people start to build on each other’s shoulders, it’s a sign that the community is stable. There is trust, growth, and a common goal — to make the best PHP applications we can and really enjoy it.
I’m really grateful for the Symfony ecosystem that allows so many other projects to grow. The stability is like nothing else in the software world.
The direction is clear, now we have to sail to new horizons 🙂
Thank you, Tomas, and all the best in 2019. Is there anything you’d like to see happen within the Shopsys Framework community?
I hope you all continue to experiment, learn and explore innovations. Luck favors the adventurous! I think your team has the skills and balls for this since you were able to successfully move to open-source in one year from a previous 15 as a private model. That’s a very brave move, and I think you’ll be able to keep making great changes.