We often read about best practices in programming, about new framework features or what's new in the next version of PHP. We read how to change " this to this " , why some technique is good or bad, or what new package you can use in your project. But all this is speculation only about the past or the present.
I'll finish reading the book « of The Inevitable » , written by the founder of the magazine Wired, in which it only about the future. Inspired by this book, I propose to look at the future of programming.
Today we are fighting technical debt (whatever that means), legacy code that is difficult to maintain and expensive to modify, but generates a lot of money at the same time. On a regular basis, we have to refactor the code, follow the DDD principles, write tests, update the PHP version for security purposes, install the latest software versions on the server and automate the layout.
There is so much current routine work that there is absolutely no time to look at dozens of other projects that our company supports ... or at least stores it somewhere on our servers. We should hire an expert to help improve every aspect at least slightly. Not because these projects are bad, but simply because there are so many technologies that we can use, and even more code that we just have to maintain.
And how will all this happen in the future?
IDE will use artificial intelligence
In the future, typing code will become easier. Our IDE will be powered by artificial intelligence, which learns from the anonymous data of other PHP projects and all open source projects on Github and Gitlab.
Thanks to this AI, when we start typing "class HomepageC ...", the IDE will know that we are creating a home page controller, that we are using Symfony, as well as its version from composer.json, and will offer to automatically add finalization modifiers to the rest of the code and strong types, based on knowledge of the PHP version being used, also from composer.json. It will generate a template for the template engine we are using and will mimic the content found in other templates that we already have in our project.
Thanks to the huge amount of anonymous data and data from public code stores, the AI will know how to best test the controller and will use this knowledge to create an optimal controller test.
Best Verified Practice
When we talk about "best practice", we do not mean what I or someone else wrote in a post or book based solely on personal experience. These opinions are often based on experiences from just a few projects and are emotionally charged.
In the future, the concept of "best practice" will be replaced by "verified practice" and will be based on real data associated with two rigid indicators - technical debt and the efficiency of coding. Tech debt will have a financial equivalent that will show how much it will cost to maintain each line of code in the future. Are you free to write static code without typed classes? The string may "cost" $ 10. Are you writing final classes with strong types and one public method? In this case, the line will cost $ 2.
These numbers will not be random, but will be based on constant analysis of a colossal amount of big data, anonymous for all projects that choose to use this feature. The code will be compared against the monetary costs that were required to maintain and improve the projects. Thanks to this feedback, the AI will also know which version is more beneficial for your particular project.
The AI will know about the context of your project and compare the data accordingly. Do you have a CLI project? It will be compared with the code of other CLI projects in this subject area. Are you making a website? It will be compared with designs from other sites.
The efficiency of coding will be determined by the "maintainability" metric of the project. It will be measured on a scale from 0 to 100 points, where 0 means it takes many hours to understand the code, and it may take days or even weeks to make changes. A code with a score of 100 will be easy for a junior developer to understand, and he or she will be able to change the code almost instantly.
IDE verified auto-completion
The IDE will be aware of these metrics and will also follow the patterns used in your code. When you start writing a piece of code whose efficiency is 40-50 points, auto-completion will pop up with a suggestion of code with the same functionality, but with an efficiency of 80-90. This is similar to the work that Rector or PHPStan do today.
Performance analysis will also be performed alongside coding performance analysis. Performance will be automatically measured whenever the code changes in the background in the Docker container, and you will be informed of any memory leaks or run-time increase. This analysis will be so accurate that it will flag the specific line or characters that caused the leak and suggest a fix that you just have to accept.
AST refactoring
Refactoring will also be more powerful than it is today. It will be based on the Abstract Syntax Tree (AST). The IDE will suggest the best refactoring you plan to do now, based on anonymous data from all open and closed projects.
Instead of referring to best practice, you will know that:
- solution A will cost you $ 3 per line in technical debt, and will be rated 95 for efficiency and 45 for performance
- Solution B will cost you $ 1 per line in technical debt, with an efficiency rating of 70 and a performance rating of 50
Are you building a startup and want to test your idea? Then you will choose option A. What if your company is stable and should remain so in the future? Then it is worth switching to option B, which is cheaper in support and performance, but slightly slower in development.
You will not have to argue with a colleague or with your boss why you should use this or that solution. You compare the numbers and then decide based on your current priorities.
Context architecture
Your code will have a contextual architecture. The AI will know when to move between contexts based on data from other projects and the final cost of migrating to them. Are you starting a WordPress project? Its OK. But what if your project gets more popular and you need to switch to some PHP framework that better suits your needs? The IDE will prompt you to switch to Laravel. One click and you're done.
Three years later, your project grows, and you will have many tasks to integrate third-party services that are already built into the Symfony framework. The IDE prompts you to migrate ... click ... and boom, you're on Symfony 9. Did you find that there aren't enough Symfony developers on the market to handle the development of your project? One click and the IDE will transfer the project to a framework for which there are enough developers at a reasonable cost.
StackOverflow versioned answers
The IDE will scan your code and analyze your coding habits. You usually write a function in 15 minutes, but now it takes almost 2 hours? In years to come, the IDE will be so good that it will notice even a slight decrease in the speed of writing code in a matter of seconds.
The IDE will then check your code, scan the responses on StackOverflow, match the responses against the versions in your composer.lock, and suggest that you use the specific piece of code that best suits your needs.
Are you worried that this piece of code is just copied randomly and breaks your project? Answer rating is no longer based on user voting, but now takes into account the percentage of use of the answer if it is successfully integrated into the project code.
Tested code snippets
In addition, code snippets are tested daily by StackOverflow itself and also before being copied into your project. It is with the version of your local environment, so you can be sure that the code will work. People no longer write versions of these answers themselves, as they did in the past. The code in the response is updated automatically with each release of the technology or framework it uses. Some answer has been given for Symfony 5. What will happen when Symfony 6 is released? The old code in the answer will be updated with the AST recipe that was released with Symfony 6. This way, the human and IDE can easily work with it.
Open-Source Activity Based Funding
A new project will be created that will link commercial companies and open source contributors. The open source project will be funded by the companies using it. Developers who contribute will be funded through a single system based on incoming money flows, with no additional fees to cover costs.
Funding will be measured using metrics such as feature impact, workload, time spent, code efficiency, etc. Thus, the code will be developed much more consistently than when it was developed by independent contributors in their spare time. A developer on an open source project will, in fact, get a full-time job funded by that project.
What will these companies receive as a reward? Community-specific promotion, pre-release releases of new versions, and direct access to expert consultants who have created the open source projects they (these companies) use.
Consolidating frameworks
~ 10 PHP frameworks currently in existence will be consolidated. The communities around PHP frameworks will learn to collaborate more instead of developing nearly identical copies of frameworks with an MVC approach.
Thanks to AST migrations, you can switch to any PHP framework. This will narrow the selection down to 3-4 frameworks. If migration between frameworks is a matter of 1 click in your IDE, then there will be no more competition based on the claim “it’s historically” and habits, but only on quality.
Reducing the number of frameworks will lead to their more narrow-mindedness - one framework will excel in API, another in CLI, third in sites with great UX.
When the entire PHP community focuses on fewer frameworks, it will allow us to invest the saved effort in developing new technologies and features.
Only 1 stable PHP version
Thanks to automatic AST migrations, there will only be two versions of PHP - stable and dev. Since updating any package or project will become very fast and cheap, there is no reason not to update to the latest version. It might take the PHP community a year or two to accept this and keep all projects in sync. But when that happens, within a month after the release of a new version of PHP, the entire open source ecosystem will use it as the minimum version.
Fully automatic and instant code updates
PHP code does not need to be manually updated. Each version of PHP will have a complete AST-based update "recipe" that you can use to automatically update the code in your project. GitHub will handle these "recipes", so when a new version of PHP is released, GitHub will automatically start sending a pull request to your repository. There will be automatic updates not only for PHP, but also for any framework or package. Like Dependabot, which was recently integrated into GitHub, but now with a code update and all backward compatibility issues.
GitHub upgrader
If you don't want to take over all the PRs yourself, you can sign up for the auto-update program so GitHub does it for you. He will also properly update the releases and their SemVer.
Automated SemVer
There will be no debate as to whether the change is a backward compatibility break or just a patch. AI will analyze the code before and after, and based on this will make decisions. He will be so smart that he will be able to determine how significant an impact a particular change has. If this does not affect any code in other projects, it will be released as a patch.
PHP RFC Based on Lessons Learned
The same backward compatibility break analysis would be possible for any RFC in PHP core code. Want to suggest typed constants? AI will tell you how many projects from the top 10,000 on Github will be broken as a percentage. Something similar is now being done manually in some RFCs.
Rethinking Backward Compatibility Break
AI will also help you generate AST migration “recipes”, so an instant update can fully handle interrupting backward compatibility. This will lead to a change in the concept itself. Backward compatibility breaks will only occur when automatic updates cannot occur and a human is required to change the code.
Try RFC locally
In addition, anyone can try the RFC feature locally right after the PR is created on GitHub. How? Github will automatically create a temporary version with a special dev tag and push that PHP version to the package registry. You create an RFC to add typed constants, submit it as a PR to GitHub and after 1 minute you can run sudo apt-get install php-dev-typed-constant to get PHP with this RFC on your local machine.
Thus, programmers will be able to try this feature even before being included in the main branch and even before voting on the RFC. In this case, even voting on new features will be based on real data and experience, and not on emotions, subjective opinions and arguments.
What does the future hold for us?
In the future, our capabilities will not be limited by our history, past choices, or rapidly evolving technologies that make our code quickly obsolete. With just one click, all of our tools are the most advanced on the market today.
This will allow us to experiment more, test our assumptions, and get real feedback. This will lead to even better automation of coding processes and inventions in the language, patterns and application architecture that we cannot even imagine today.
"The best way to predict the future is to create it."
Happy creation!