You may add "yet" to this title! Sometimes, things are what they are simply because nobody knows how to do better.
However, it does not mean everything is a good idea.
PHP doesn't support multiple inheritance
You simply cannot do the following:
class Child extends Parent1, Parent2 {}
However, many developers would think there are better approaches, like using interfaces to force classes to implement specific behaviors.
Note that you may still apply some kinda of multiple inheritance to those interfaces (if that really makes sense in your case):
interface A {}
interface B {}
interface C extends A, B {}
However, that's not the best argument against multiple inheritance, to me. Many programming languages focus on simplicity and readability over complexity.
Introducing multiple inheritance could lead to lots of misuses, not to mention the Diamonds problem, which would be problematic for high-level languages such as PHP.
It's best if you can avoid unnecessary complexity.
PHP does not support multi-threading
Many programming languages provide built-in tools to execute multiple threads at the same time (e.g., Java, C++).
Pthreads tried to introduce multi-threading in PHP but Joe Watkins the creator of pthreads and parallel announced in February 2019 that:
pthreads will no longer be maintained after PHP 7.4 due to architectural flaws.
Source: PHP documentation - phtreads
If you want to dig further, you may check parallel, which is inspired by Go concurrency.
While parallel is pretty cool, do you really need such complexity in your case?
If you need a built-in mechanism for asynchronous processing, it is now possible with Fibers (since PHP 8.1).
Fibers allow you to write interruptible functions.
While Fibers are pretty cool, do you really need such complexity in your case?
Using third-party solutions such as ReactPHP or Swoole could be a better choice, especially if you only need an event loop.
Better than that, you may build a queue mechanism that can handle messages and retry failed jobs.
The Symfony component HTTP Client also supports various asynchronous operations (e.g., concurrent asynchronous streamed and multiplexed requests/responses).
PHP is not meant for real-time processing
PHP is an interpreted language, which is incompatible with intensive operations and systems that require low latency and high predictability.
While is true, why would you use PHP for High-Frequency Trading, streaming, online gaming or high-level supervision of machines and processes?
Wrap up
PHP is meant for the web and many other creative uses you may know.
I hope it will keep its simplicity, as it is definitely a feature.
Top comments (4)
very good post!
I often wonder why companies use PHP (and Laravel specifically) to build high-demand APIs. In my view, it is not the optimal language for such tasks. PHP is not my first choice for building APIs, and if it must be used, I would prefer a framework designed specifically for APIs, as I find Laravel too large and complex for this purpose.
In one of my past projects, I needed multithreading capabilities. Since PHP does not natively support multithreading, I had to refactor the processing functions into separate scripts and call them independently to emulate multithreading.
I don't understand people that think frameworks are too large because they only want to use one part. When a tv has a browser and apps or has the possibillity to use it as a picturescreen, will you not buy it when it has the screensize you want, the sharpness, and all the other things you are looking for?
Laravel is in its simplest form nothing more than a request router with lifecycle hooks. It provides you tools to make your development time shorter. But if you want to build them yourself, laravel isn't stopping you.
That is exactly the point of a framework in my opinion—it makes my life easier with pre-built functions, eliminating the need to code certain things from scratch. However, it's crucial that the developer chooses what additional features to install. I dislike it when frameworks come with built-in components like mail servers or web servers because I might not need them, and rerouting to use my preferred solutions takes extra time.
As far as I know, Laravel comes with its own web server, making it much more than just a PHP framework with routers and hooks. The preferred method of installation involves using their VM, which I believe is overkill for a PHP framework. I prefer using the Yii2 framework on an NGINX server in a Docker container.
To elaborate, I would not use Laravel to build APIs in PHP; I would use the Slim framework, which is built specifically for APIs.
Don't get me wrong—I love frameworks. They provide more power and speed to get things done in a more organized and space-efficient manner.
As for your comment about TVs, I only use 4 apps on any smart TV, so why do I need the other 20 cluttering my screen? Simplicity is key for me.
IMHO, Laravel has a mission beyond its fancy features. It aims to ease common tasks, (including creating APIs) and provides advanced modules to help developers applying good practices, regardless of their experience.
However, for high-demand APIs, it's always the same problem. You cannot expect such performances from a generic tool. It's just not meant for that, and dev teams often build their own tool or use minimalist frameworks (e.g., Slim).
If you add something to your project, you need to maintain it.
I really do believe simplicity is a feature, but it does not necessarily mean more time and effort. Choosing the right tool can save time.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.