I don't really understand why in 2020 there's still this kind of blind hatred against this language. It often comes from horrible bad memories from previous versions or old frameworks.
Objectively, compared to other languages i've been working with it is more than OK. Despite it's lack of "style" it is easy to understand, host, tests, diagnose and it is powerfull for web applications.
I've been working on a SaaS API with Symfony now for 2 years, our metrics are good...
It is a good tool, it builds good softwares
It's essentially sinking in popularity because of bad faith and lack of hype, really sad !
> I don't really understand why in 2020 there's still this kind of blind hatred against this language.
Well, the language is burned for a whole generation of devs, and it's hard to lose the nasty stench once it has settled.
A major reason might be that you don't touch again what you learned to dislike. Because you known anyway that it will be painful, why go for it?
> It often comes from horrible bad memories from previous versions or old frameworks.
Those old versions and frameworks are still around. Companies don't lose their legacy fast.
> Objectively, compared to other languages i've been working with it is more than OK. Despite it's lack of "style" it is easy to understand, host, tests, diagnose and it is powerfull for web applications.
That always was the case with PHP. Doesn't say whether it has lost it's old flaws.
> It's essentially sinking in popularity because of bad faith and lack of hype, really sad !
Is more losing because of competition. PHP still is mainly a web-stack backend-language that can't offer much in other areas. But now there are other languages who can equally shine on backend, while also shine on other areas. So obvisouly people go for the language which can give them more, instead of less.
I haven't found any good arguments against PHP in the comments here, just pure hate.
Let's name a few of the arguments people are making:
1. Its variables start with $ and that is ugly: I mean, come on, I won't even entertain this bigotry.
2. It used to be better before: This is just pure nonesense, before OOP PHP wasn't good to create any big and well-structured application, it is ironic because most of the bad opinions about PHP come from people who used it a long time ago. Besides, you can still use PHP as you used to, but now you have more tools at your dispossal, You are free to use it as before.
3. It is trying to be Java: Well, sure it is more like Java, only less verbose and easier to write. Developers can be much more productive in PHP. And moving in the direction of Java is not a bad thing as the language moved into the Enterprise space. I worked with Magento every day and I am glad the language is more than Java than it used to be, it means we can organise our code better. Again, ironic that some people who mentioned this as something bad about PHP, then went on to say they prefer Java.
4. Composer has made the language worse: Honestly this is so ridiculous... so now having package managers is a bad thing? I haven't met an actual professional PHP programmer who holds that opinion. All of them like composer, it makes reusing code and creating apps in PHP much easier.
At the very least it seems nonsensical and cargo-cultish: As a non PHP-er, what is the actual purpose of $? In Perl, it indicates variable context (for better or worse, there's more than one, so it has to be indicated somehow). In shell, it indicates the substitution of variable name by its value. In PHP...I draw a blank. It really seems like an "I wanted my language to look like some other language but I had no idea what it should be doing" kind of thing.
but because early PHP was more simplistic than Perl it only has $.
Powershell also uses $ for variables.
Regardless of etymology of the $ sign and the usefulness of it, personally I like it because it makes it easier for me when I'm reading code, especially if you are scanning fast, to differentiate variables from symbols. Yes, you can get that with your editor too, but for me it is easier to associate the $ sign with a variable rather than a specific color, sometimes you don't have coloring available like when in command line going thru diffs, cat, nano etc.
It seemed kind of obvious to me even at that time that it was taken from Perl. I just didn't get why. PHP could have lifted IMPLEMENTATION DIVISION from COBOL, but likewise, there would have been no point either (fortunately it didn't do that!).
Early web was written in Perl, I guess it was the classic approach of lets borrow what is already successful and in end PHP won over Perl so it worked too. Bill Gates would have been proud.
It differentiates variables from global constant things (constants, class names, function names, ...) for which the scoping is different. So you can have $strlen = strlen(...);
Off the top of my head, I struggle to come up with situations where you'd need an $ to distinguish class names or function names syntactically. Hell, in Lisp I can do (let ((length (length seq-1))) ... (length seq-2) ... ) just fine and it still works as expected, so no special characters necessary either.
Plus, to have different scoping rules was considered a good idea? Weird scoping issues were why I gave up on Ruby fifteen years ago; perhaps it was a good idea that I got never that far with PHP. But I'm intrigued now; what exactly are the scoping differences in question?
TBH, I don't know lisp and I have no clue what you just wrote. Someone new to PHP can just be told $something is how variables look like. And they will recognize variables forever from then on. What's a variable in that lisp code, or in any general lisp code? I have no clue at first glance.
I didn't say it's necessary for the parser, but it's useful for the learner/user.
It means the start of a variable name, as simple as that, it isn't anything significant. Maybe it was made to make parsing the language easier at the time, who cares?
You can get used to that in 10 min and move on with your life, it is not a reason to not pick up the language, it's bike shedding.
There was a number of other reasons why I didn't end up using PHP, so it was a bit like death by a thousand cuts. It was not the reason for me, just a small showcase of the weirdness for a newcomer.
> 3. It is trying to be Java: Well, sure it is more like Java, only less verbose and easier to write. Developers can be much more productive in PHP.
I suppose if you are equating extra keystrokes to productivity, then sure. However, Java has vast ecosystems and standard libraries that dwarf most languages. The real gains in productivity are in not re-inventing the wheel for everything. Verbosity has little to do with productivity in the bigger picture.
You are proving my point by defending Java against PHP because my argument was that being more like Java isn't a negative thing.
The productivity point was a secondary point but when it comes to building websites I think people can build faster in PHP although I guess that depends on many factors.
I guess I am not following your argument. Are you not saying that since PHP is less verbose than Java, this is better for productivity? After which you then follow up and say that PHP becoming more like Java is not bad? Seems contradictory, no?
My point was that it was ironic for people to say that PHP becoming more Java-like was a bad thing, but then they said that they prefer Java to PHP.
You are right, I did sneak in there that I find PHP less verbose than Java as an advantage, since most people complain about how much typing you need to do in Java I thought this was worth highlighting.
However personally I think PHP evolving to be more similar to Java was a good thing, even better because imo they copied the good parts, ie: OOP instead of the verbosity but that's up for debate.
In short, becoming more like Java was good, but PHP isn't Java and has its own advantages for web development, imo this is that it is less verbose and easier to write.
I have my reasons to _despise_ hosting PHP from an operational perspective. These mostly come from having to host ready-made PHP applications like Nextcloud, Wordpress, Dokuwiki, etc.
1) 'Language configuration' kept in a php.ini that is usually not shipped with any project. Instead, each project tells you what flags to flip so that it runs, but very often every distribution ships PHP with slightly different flags, effectively making it _very_ hard to have a 100% correct php.ini.
2) 'Deployment configuration' that is additionally present in your FPM/apache configuaration. Again, you have to be told by a project that that these given options (often related to timeouts and request size) have to be set. Many projects just assume you have some 'sane defaults' like things bumped up from the defaults. Again, very difficult to get reproducible deployments of an app, unless the developers are very insistent on documenting everything.
3) Extremely painful to debug. If 1) or 2) are broken and a connection terminates during an upload with some 400 error, the error can be in multiple places: nginx/apache, php-fpm, or the PHP code itself. Each one of them logs to a different place, or not at all. It's difficult to actually understand the _source_ of the error. Good luck. Bring strace.
4) Broken upload model. If I understand correctly, all file uploads in PHP must end up on the local filesystem, and they are impossible to directly stream onto something like S3. This means that my Nextcloud instance will first save a few gigs of data on /tmp, and then only punt it over to S3. Gross.
5) Annoying to host in containerized environments. Both Apache and nginx are the kind of applications that insist on doing a bunch of setuid()s, thereby breaking on hardened containerized environments. Not to mention having to host a nginx+fpm/apache combo per application just seems wasteful, but there's no other easy way to deploy PHP apps in a containerized way that I'm aware of.
6) Configuration woes with rewrites, static files, etc. This is related to 2), in which you have to spend a bunch of time configuring your HTTP server in order to split up requests between static file serving and PHP, set up rewrites, and hope you don't accidentally introduce a security vulnerability.
All in all, compares to something like 'here's a go binary, run it, push HTTP traffic to it, it will serve its own static files, too', PHP is an _extreme_ pain in the ass to host.
You're not being fair to the argument #3. PHP is becoming a less good Java. That's the problem. It's like Java, except it doesn't have generics, doesn't have real data structures (List, HashMap, Deque), no threads or async, no method/function reference or typed function parameters, etc.
So the whole "It's trying to be Java" is more like "What does it offer that's better than Java? Because Java has stuff that is better than PHP."
And I'm saying this as someone who doesn't like Java at all.
It doesn't need them IMO. It brings no benefit to the language, really. They would need to be type checked at runtime, which can become quite expensive. Static analysis is a better option for an interpreted language. Read this answer from Nikita (one of the top PHP contributors) https://www.reddit.com/r/PHP/comments/j65968/ama_with_the_ph...
> doesn't have real data structures
Untrue. See https://www.php.net/manual/en/book.spl.php It's usefulness is limited though, because it's rare that you need those types of data structures for web applications.
> no threads or async
Untrue. All kinds of projects like Swoole (gives you a runtime similar to Go) and ReactPHP (runtime similar to Node) and https://github.com/krakjoe/parallel for lower level concurrency. There's also pthreads https://www.php.net/manual/en/book.pthreads.php But again most of these aren't necessary for most apps because of PHP's request-response model. Useful for one-off services though.
> It doesn't need them IMO. It brings no benefit to the language, really. They would need to be type checked at runtime, which can become quite expensive. Static analysis is a better option for an interpreted language. Read this answer from Nikita (one of the top PHP contributors) https://www.reddit.com/r/PHP/comments/j65968/ama_with_the_ph...
Right. You need to use something like Psalm if you want the benefits of generics, which is basically a tacked on type system. Having static checking is absolutely beneficial. I'd be willing to bet good money that you don't write PHP without typehints and/or Psalm/PHPstan.
> Untrue. See https://www.php.net/manual/en/book.spl.php It's usefulness is limited though, because it's rare that you need those types of data structures for web applications.
You're totally right. I was thinking that you still needed to explicitly enable SPL, but that hasn't been true for a long time, IIRC. So, fair enough. I was wrong here.
> Untrue. All kinds of projects like Swoole (gives you a runtime similar to Go) and ReactPHP (runtime similar to Node) and https://github.com/krakjoe/parallel for lower level concurrency. There's also pthreads https://www.php.net/manual/en/book.pthreads.php But again most of these aren't necessary for most apps because of PHP's request-response model. Useful for one-off services though.
pthreads was never worth much. It never worked on web servers and is now deprecated. Parallel is a PECL extension, which may or may not be considered part of PHP, IMO. I believe it also doesn't use threads unless you use pthreads (which you should/can not). So it's just multiple processes- not threads or async. I don't know much about Swoole, etc, but those are frameworks- not PHP itself. Also, I believe Swoole is process based, not thread or (true) async. I could be mistaken. So, again, AFAIK, PHP does not have threads or async.
That's not what I meant. My wording was poor. I meant specifically `callable`. You can't typehint the inputs and outputs of `callable` parameters. So passing around lambdas, etc, is not robust/safe.
> You do those like this: [Example::class, 'someFunction']
Yeah... an array of two strings. Again, I should've been more clear. I know that's how you refer to functions in PHP. But it's not the same as actually getting to write Example::someFunction and knowing that the inputs/outputs line up with whatever you're doing. If you're lucky, your PHPStorm or whatever can tell where you're trying to refer to a function and maybe point to it for you, but otherwise, it just thinks you're passing some strings around, because you are.
> I'd be willing to bet good money that you don't write PHP without typehints and/or Psalm/PHPstan.
Yeah, think of it like Typescript. Same idea.
> Also, I believe Swoole is process based, not thread or (true) async.
It's a coroutine model, like Go. Very fast. But I don't use it because it's primarily a chinese community, lots of the docs are in broken english. But it's an impressive thing anyways.
IMO, you don't need threading in PHP, there's not really that many situations where it would help during a request-response flow. People generally delegate slow tasks to job queues, which often use https://www.php.net/manual/en/function.pcntl-fork.php to fork off workers. Works great.
> That's not what I meant. My wording was poor. I meant specifically `callable`. You can't typehint the inputs and outputs of `callable` parameters. So passing around lambdas, etc, is not robust/safe.
You can though. `fn(SomeClass $foo) => $foo->doThing()`
> and knowing that the inputs/outputs line up with whatever you're doing
Fair enough, but you can use reflection to look at the callable if you care enough. It rarely matters.
> It is trying to be Java: Well, sure it is more like Java, only less verbose and easier to write. Developers can be much more productive in PHP
This sounds like kool-aid. Any productivity gain from reduced verbosity would be minimal. Typing out two extra keywords for your method signature is not going to affect your productivity in any real way in reality.
And it being dynamic. If just want to dump some JSON or a CSV into an array to do something with it it is probably going to be much quicker than in Java.
The latest version of PHP that I used was 5.3. The power, and disadvantage, was that it was basically a scripting language which allowed for quick prototyping and easily making some of a site dynamic and allowing for templating. For the more serious/involved/enterprise applications, a lot of workarounds were needed to cache database connections etc.
Lots has improved: ide support, jit, package manager. In doing so it became more mature now joining the realm of more serious, enterprise, languages which had all of this for ages. As such it is also being compared against those languages. At the same time templating is now easier and more cheaply done through static site generators. So imho PHP falls a bit in the middle and it is only kept afloat because of the likes of Magento, Wordpress, and other big products built on top of PHP that thrive by being modifiable by practically any developer.
> I worked with Magento every day and I am glad the language is more than Java than it used to be, it means we can organise our code better
Do you consider Magento being a framework you are happy to work with? I'm also working in Magento 2 and honestly it's a painful experience. It's a so bloated framework that without cache enabled the development is completely awful.
There is a discrepancy between what’s hip, and what’s actually used. On places like HN where everyone is in love with Ruby... errr... Go.... errrr I mean, Rust, you’d think that those languages are the what’s what.
Then when you look at the job market, you get a very different picture of what actually gets used. In my country there hasn’t been a single job posting for all Rust in all of 2020. There’s been a single mention of Go as a “nice to know” PHD job at Google Denmark and there is just a single company who has had openings for Ruby. Hell even with everyone’s favourite Python, almost every job involving it is in DataScience and needs you to be a mathematician first, analyst of some kind second and a programmer third. There are a few django jobs, and good for those guys, but in general, even python doesn’t see that much general usage.
The vast overwhelming amount of jobs that’s been listed in 2020 in Denmark have been for C#, PHP and JavaScript, with JAVA still hanging in there somewhat, though typically bundled with whatever they call JBOSS these days.
So unless you’re smack in the centre of Silicon Valley, I probably wouldn’t worry too much about the hate PHP gets.
> One of two PHP major web frameworks borrowed everything they could from it.
Weird flex.
So you're saying that an aged veteran in any sport who observes and learns from his younger peers should be looked down upon as being on their bandwagon? Their growth, improvement and continued success should be discounted?
This is because you‘ve built up expertise and know the ins and outs of the language and frameworks (which are often very complex and idiosyncratic to achieve their cleanliness and expressivity). You know what to use, how to use it, what to avoid, how to debug stuff etc.
However for people who have not invested this time and effort it is an objectively worse language than other web focused ones in many dimensions.
PHP is a workhorse for the web and still the most important language next to JS in that regard. But there is a reason it is declining (slowly) as well.
I think that's it. No argument that it's improved, so much, but if you're not already using it then it's hard to pick it over other options. Good luck to the fans though, you can do anything you need with it and if you enjoy it all the better.
That's correct. It turns out that it's also bad, though. People don't like to hear it because I'm "just a hater", and maybe one or two of these issues isn't a deal breaker. And yes, you can write real, useful, applications in PHP, but it's a terribly awkward language with a lot of missing features and sloppy dynamic typing nonsense.
* No (real) async or threads (pthreads never worked on backend and is deprecated anyway for those who always mention it in response to me)
* No generics
* Interfaces must be complied to at class definition
(leading to verbose nonsense like the "adapter pattern")
* No const or immutability
* `array` is a shitty hybrid of an actual array and a dictionary and it sucks at both
* No other native data structures beside the shitty `array` mentioned above
* No ability to typehint callable function params
* switch statements use loose equality checks, so you should avoid them
* foreach is broken and leaves a dangling reference
* `array` keys are automatically cast to int if they can be, which is broken and insane. (E.g., if I use `array` as a dictionary and one of the keys is the string "123", it will NOT store the entry as key-value pair: "123" -> $data. It will instead store $data in the 123rd slot of the "array". Iterating this `array` with an index will end in a bad way).
But surely someone will drive by and say that none of these things matter and that an experience PHP dev would never be bothered by any of these things, etc, etc. "You can write bad code in any language."
But... you can always just choose a better language if you have the choice. I feel like people get Stockholm syndrome over their tech choices. It all sucks, but some suck worse than others. Don't tie your identity to shitty stuff like programming languages: "I'm a PHP dev." "I'm a Rust dev." Give me a break.
People keep saying “PHP in ${current_year} is actually great, it only sucked in ${current_year-5}!” - I feel like it still sucks[1] today, but it’ll take 5 more years for the fans to realise it, when they have the PHP from ${current_year+5} to compare against :P
[1] Being slightly hyperbolic - I won’t deny that you can do good things with PHP, as you can do good things with any tool; and AFAIK it’s still unmatched when it comes to low barrier of entry and shallow learning curve.
(I’m coming from the perspective of someone who mostly uses rust, python, and PHP7.3, with odd bits of Hack - in the past week, PHP7.3 has frustrated me with lack of typed arrays, lack of typed properties [fixed in 7.4! Only took 5 years between the introduction of type declarations and consistent support for type declarations...], and dictionary keys being automatically cast from string to int if they look vaguely numeric. It’s a shame Hack never took off in the open source world, as it’s basically “What if we could reimagine PHP without the legacy baggage?”)
The key to becoming a person who thinks PHP is great now is to primarily use features that have existed for more than 5 years. For me, PHP 7 was PHP 5 that was faster and had some nice little bits of new syntax. They started down the type system road but I avoided it then.
Now it seems like the basic type system is in place, great. This new stuff in the article I'll probably start using it when 8.4 drops.
5 years is an exaggeration, but staying a version or two behind really helps you stay sane.
By the way I found Hack/HHVM thoroughly disappointing. Tried running some fairly complex apps on it and it felt like they reimagined the legacy baggage. Seems like PHP itself borrowed a lot of ideas from it though.
Probably the package/ framework ecosystem. There is also a self reinforcing quality, there are a lot of devs which in turn encourage people to do projects in PHP to access those devs.
It depends on your goal. I personally think PHP still wins for a solo developers in speed of feature creation. Think of the ratio of business value per development cost. Someone should find a way to objectively measure this.
Same here. Sure, PHP in 2020 is a mostly passable language. But then next to it you have Java/Kotlin/Scala, Go, Clojure, Node w/ TypeScript, even Elixir is pretty awesome.
Though, to be honest, I'd probably use PHP over Node even with TypeScript because the Node ecosystem is such garbage.
You just have to really like Laravel, I guess, to choose PHP in 2020. Which is totally fair. I haven't used Laravel, but people do rave about it.
More than anything, I find the language $ugly. Is that fair? No. Am I being unreasonable. Yes. Do I love PHP? Gross. I just have to live with it and go past the ugly syntax. It’s like an unhappy marriage. It’s just fine.
I think PHP is a fine language if you are working on an existing application or are building on top of symfony but I’ll begin second guessing all your design decisions if you increase the default execution time of php from thirty seconds to over five minutes. I submit PHP does not belong anywhere outside the request response cycle. If you use it for other stuff, you are not wrong. I mean I’ve used puppeteer and node js to capture screenshots and I still think that ideally JavaScript should only exist in client-side web browser based development. I would never voluntarily do any of the react native or express/hapi server side development with JavaScript. I will do it if there is money involved, it just isn’t my preference.
It is ok to have a preference to do non web work with PHP but you owe it to yourself to at least try something else before saying you prefer it over everything else.
There is nothing wrong with $ though. That’s just insane. Also I’m very excited to see Drupal 9 being released with twig 2 support and more recent symfony support. I just think you should at least evaluate other options before saying “everything goes better with php sauce” just like the JavaScript crowd should stop and get some help before using JavaScript for native development and or server side development.
Maybe think of money everytime you see the $ symbol, to make it more palatable? :P
On a serious note, I find the JS ecosystem more annoying than PHP. Modern frameworks like Laravel (Laravel is nice to work with), PHP is more than enough for its intended use - web applications. PHP 7 has good performance improvements too.
The funny part is that all the hate they have towards PHP, pretty much most languages have similar or other problems. I say this as someone who loves languages like Go, Python but I run a SAAS business in PHP which brings in close to 7 figures ARR and employs 15+ people. All these developers shitting on PHP are basically the elitist form of "I don't do PHP so you shouldn't either because it sucks and <my shiny language> is so much better".
I know people who run decently sized and successful businesses in a variety of mind-numbing technology (try FileMaker scripting or shell scripting) but that definitely doesn't mean those things don't often suck and that there aren't advances in PL's that don't or won't lead to better software. (I personally don't use PHP at all because I haven't yet seen a reason to use it for any new projects over Python or TS. Is that new match expression proper pattern matching? ;))
It's pretty hard to draw a link between these things and commercial success, but it somewhat unseriously reminds me of Jonathan Blow's warnings that eventually everything is just going to fall apart.
Yes I am not necessarily disagreeing. I am saying that people who shit on PHP think that other languages are somehow this magic wand that is so much better. I challenge the "so much better" part because the cost vs benefit matters.
Because those of us who know and have used several languages tend to develop a preference for expressiveness, terseness, safety, and dare I say, elegance.
PHP (and JavaScript) gained and maintain their relevance, despite being inferior languages, because of their historical placement. I'm sure COBOL has improved over the years, and we know it is still used and "needed"... because of its historical placement. But you probably wouldn't use it, either, unless you had to (or you didn't know a better alternative).
> It often comes from horrible bad memories from previous versions or old frameworks.
Not only that. There is a huge amount of devs hating PHP w/o ever having worked with it. Same with Perl.
Objectively, compared to other languages i've been working with it is more than OK. Despite it's lack of "style" it is easy to understand, host, tests, diagnose and it is powerfull for web applications.
I've been working on a SaaS API with Symfony now for 2 years, our metrics are good...
It is a good tool, it builds good softwares
It's essentially sinking in popularity because of bad faith and lack of hype, really sad !