PHP 8.3
php.net
php.net
While there's nothing inherently wrong with using PHP for tasks Java already handles well, given Java's proficiency in its domain, it's not always necessary to replicate these functions in PHP.
However, there's a tendency to undervalue PHP-based applications, often labeled as 'home.php-style' apps. It's true they can become unwieldy and unmaintainable if not properly managed. Adhering to good practices is essential, but it's also important to remember not every project needs a complex solution like bootstrapping a Laravel project for a simple task list. Everything comes with its own set of trade-offs!
Let's face it, a major advantage of PHP nobody talks about is that devs are cheaper.
I don't mean this all in a bad way, I have seen PHP used in high quality code-bases for websites of medium sized companies. But you are limited to input/output operations. However, there is also an advantage to this, as the PHP devs I have seen are more prone to trying out new tools and not reinvent the wheel in source code.
Also, I want to shout out to the guys making Sulu CRM. Loved working with it, too bad it's PHP and symfony only.
Do you mean "less prone"?
Edit text file on server, refresh page in browser, see your changes.
That's really difficult to pull off with Java.
You are technically right about changing files of course, but remember:
- PHP speed is all about caching. Changing a file means rebuilding (all) caches.
- PHP debugging is nothing worth bragging about. Java is way more powerful and the jvm supports runtime reload of methods as well.
This also goes together with the fact that most php devs are println devs (from what I have observed).
And then there are other things like maintenance of old php applications is a major headache because on mac old php versions just disappear in brew. And new PHP releases like to break A LOT.
I have the opposite experience:
Because PHP and package management is relatively new (Composer is from 2012, compared to CPAN's general availability in 1995), I haven't seen more wheel-reinventing than among PHP programmers.
Even the standard library seems to be reinventing its own wheels. I'm looking at you, mysql_real*_escape_string.
You're presenting this as if it's a feature. I think that's a good summary of PHP and its culture's relation to types.
With great flexibility comes great responsibility
I don't think there's that. In every thread about PHP, many people come in to explain this (edit: this = how good PHP is for use-case X, or how good it is holding up). Every time.
"We" all know PHP has its very well-fitting sweet spot. Its use-cases where it shines.
I do think, though, that the list of use-cases and the size of the sweet spot is not as big as the usage of PHP makes it out to be. What I mean is: there are many situations in which PHP is the best solution. But in many places where PHP is employed, it is not the best solution (anymore).
EDIT: All that to say, I get it, and for my part I'll try to tone it down. Thanks for listening to this old(er) guy rant.
A current example for me is SQL vs ORMs. I feel like I'm more productive building SQL queries in my application (ideally using a query builder API), than using an ORM. Because SQL was created to be a language for manipulating relational data, and thus does the job better than the indirection introduced by an ORM framework.
I think Elixir with Phoenix and LiveView can give PHP a run for its money. But PHP is a beast.
HTMX, Laravel, Livewire, alphine.js are all the things that are what these insane JS SPA frameworks aren't. Simple and intuitive.
I'm a JS guy and I'm convinced this way of orchestrating the UI from the server is really the future of full stack dev.
At least to solve 80-90% of use cases. There are still some situations that require client side components with APIs but it's really a minority. Doesn't make sense to focus all your efforts into a complex solution that is appropriate for a minority of use cases.
Write a few lines, upload it, boom it works. Quick and easy.
There is a place for typed & strict languages and a place for pragmatic ones.
But php got shamed for it so badly they got into an identity crisis, for the last decade it’s slowly been trying to become Java and do everything correct.
Same with Wordpress, before I could just make a plug-in with one php file & a few lines. Now I have to create a separate npm project and build for every tiny change
Mind you, the "old ways" still work - you can still write a few lines, upload it, boom it works. Projects around PHP might have developed different ways of working, but that's because of problems in the old way - and that's not a fault of PHP, it's a plus that things move in a more maintainable and type-safe direction. You even reap some benefits when doing a "write a few lines, upload it, boom it works" workflow.
That's not to say PHP isn't been overcomplicating itself & hasn't fully embraced why it's so succesfull and improved that part: it's easy & practical.
How can it be even easier? For instance even simpler hosting? With things like vercel, and app engine PHP isn't necessarily the simplest choice in hosting sites anymore.
A Vercel for PHP would be awesome.
Do you have specific examples for things where PHP has been overcomplicating itself? Most complex things seem to actually make things easier for newbies (e.g. typing can be a great help).
Because it was very accessible for people to get into it without being you know, a 10 year programming veteran at least.
Now all those newbies are out creating 400 npm dependency projects heh
Sure. Wouldn't it be nice to allow these people to write better code without having to change their language?
When you reach that point you may as well be using ACF, as it's so much simpler and doesn't require rebuilding frontend scripts anytime anything changes.
PHP was a dumpster fire. It's not "pragmatic" to have trivial SQL injections everywhere that are difficult for non-experts to fix. It isn't "pragmatic" to have user hostile error messages. It isn't "pragmatic" for different parts of your standard library to disagree about core design principles. It's a hundred different recipes from around the globe just thrown into a blender for a few seconds in the hope the result will be "fusion cuisine" when it's barely even food.
I wrote a whole bunch of PHP ~15 years ago for money, and before that I wrote some for the comedy site friends and I ran in the 1990s, I also had the misfortune of picking up a card in my scrum the other month where I had to modify some PHP. It's changed. It hasn't changed anywhere near enough to justify itself.
I would rate PHP3 era PHP as a 0/10 maybe just use static HTML instead, and modern PHP is maybe 3/10 where it's better but it's just not better enough to use if you could pick something else.
And it's not like it's no longer possible to write quote-unquote "bad" PHP -- if nothing else, PHP is backwards-compatible to a fault.
They're still disabled by default on FreeBSD - my PR is pending, and the patch has been in testing in ports for a while: https://github.com/php/php-src/pull/12288
I wonder if I'd have just started off immediately using something like Java if I would have been as effective? Early PHP's sloppiness (paired with early javascript) gave me a lot of flexibility and allowed me to learn things more deeply.
I’d take PHP for a new project in a heartbeat if the shoe fit. My last real PHP project was Laravel+Inertia+Vue and it was a really great workflow for me and my team.
Almost everything but async/threads that I use in Java stuff has an 1:1 mapping.
Something like https://github.com/mridoni/llxvm
I think that's more a framework/library philosophy than anything else. When I dabbled with PHP + symfony, I worked with some of the most clean APIs I've seen to this date.
The best example to show this is that you can `foreach()` over an object. It wasn't a deliberate feature but rather an artifact of how objects are "syntactic sugar over Arrays" and how Arrays are really just hashtables.
And it becomes problematic with the many exceptions that all the functions operating on Arrays have. Almost all important functions' documentation (edit: on arrays) goes something like "if the array key is a string, it will act like X, if it is a number it will act like Y". With some going like "if one of the keys is a string it will X, otherwise it will Y". And Y and X being rather different in return values, errors and such.
I can understand that PHP has a really strong preference for strings - HTTP is only and all strings after all - but the mess around arrays is real, dangerous, and has bitten me, my companies and many of my clients many times over. For decades.
Yeah, great. Now I have two problems.
> downloadable binaries on Windows
I am on Linux.
> Official docker images on dockerhub
Yeah, great. Now I have two problems.
> Not sure where you saw those 9 pages
In the official documentation, https://www.php.net/manual/en/install.unix.php
<?php
use Override;
//...
#[Override]
public function overridenParentFunction(string $stuff) //...you're going to get a mix of yes and no depending on what you're trying to do. lots of things have been deprecated over the years.
good to see that php's upholding the tradition of putting the K in Quality ;)