6 ms·

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 sta

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.

spockz 6y ago
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.
jhgb 6y ago
> 1. Its variables start with $ and that is ugly: 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.
- megous 6y ago
  It differentiates variables from global constant things (constants, class names, function names, ...) for which the scoping is different. So you can have $strlen = strlen(...);
  - jhgb 6y ago
    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?
    - megous 6y ago
      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.
    - withinboredom 6y ago
      You can do: $strlen = 'strlen'; echo $strlen('test'); I’ve also seen things like this: $return = ... You can’t use a keyword as a variable in most other languages.
mtberatwork 6y ago
> 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.
- dcabrejas 6y ago
  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.
  - mtberatwork 6y ago
    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?
    - dcabrejas 6y ago
      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.
hhjinks 6y ago
> 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.
- robryan 6y ago
  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.
bluntfang 6y ago
>I won't even entertain this bigotry. I'm not sure using a word that has historically been used for people who are racist is the right word when talking about programming languages.
- spacechild1 6y ago
  You might want to look up the definition of "bigotry" then...
  - bluntfang 6y ago
    The dictionary definition does not change cultural context.
ragnese 6y ago
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.
- przemo_li 6y ago
  PHP have nice libs as extensions for those data structures. It's std variants that should be avoided.
- francislavoie 6y ago
  > it doesn't have generics 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_phpstorm_team_from_jetbrains_on/g83skiz/?context=3 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 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 https://github.com/krakjoe/parallel for lower level concurrency. There's also pthreads https://www.php.net/manual/en/book.pthreads.php 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. > typed function parameters Completely untrue. https://www.php.net/manual/en/functions.arguments.php#functions.arguments.type-declaration https://www.php.net/manual/en/functions.arguments.php#functi... > no method/function reference You do those like this: [Example::class, 'someFunction'] I hate it when people write such blatantly misinformed comments. Sigh.
  - 6y ago
esimov 6y ago
> 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.
q3k 6y ago
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.

spockz 6y ago

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.

jhgb 6y ago

> 1. Its variables start with $ and that is ugly: 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.

megous 6y ago
It differentiates variables from global constant things (constants, class names, function names, ...) for which the scoping is different. So you can have $strlen = strlen(...);
- jhgb 6y ago
  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?
  - megous 6y ago
    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.
  - withinboredom 6y ago
    You can do: $strlen = 'strlen'; echo $strlen('test'); I’ve also seen things like this: $return = ... You can’t use a keyword as a variable in most other languages.

mtberatwork 6y ago

> 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.

dcabrejas 6y ago
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.
- mtberatwork 6y ago
  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?
  - dcabrejas 6y ago
    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.

hhjinks 6y ago

> 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.

robryan 6y ago
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.

bluntfang 6y ago

>I won't even entertain this bigotry. I'm not sure using a word that has historically been used for people who are racist is the right word when talking about programming languages.

spacechild1 6y ago
You might want to look up the definition of "bigotry" then...
- bluntfang 6y ago
  The dictionary definition does not change cultural context.

ragnese 6y ago

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.

przemo_li 6y ago
PHP have nice libs as extensions for those data structures. It's std variants that should be avoided.
francislavoie 6y ago
> it doesn't have generics 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_phpstorm_team_from_jetbrains_on/g83skiz/?context=3 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 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 https://github.com/krakjoe/parallel for lower level concurrency. There's also pthreads https://www.php.net/manual/en/book.pthreads.php 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. > typed function parameters Completely untrue. https://www.php.net/manual/en/functions.arguments.php#functions.arguments.type-declaration https://www.php.net/manual/en/functions.arguments.php#functi... > no method/function reference You do those like this: [Example::class, 'someFunction'] I hate it when people write such blatantly misinformed comments. Sigh.
- 6y ago

esimov 6y ago

> 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.

q3k 6y ago

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.