10 ms·

There was never anything wrong with PHP, really. * If you wanted to scale it horizontally, it was ready to do that 15+ years ago * No problem running it compl

There was never anything wrong with PHP, really. * If you wanted to scale it horizontally, it was ready to do that 15+ years ago * No problem running it completely stateless * Deploys are completely sane and predictable, it's just a bunch of files, and even when composer came along it didn't really change that too much * Performant enough as far as the interpreted web languages go * No problem writing a RESTful backend in it and fronting completely "modern" client facing tech on the top if you want * Server side rendering since day 1 Like, it came down to people complaining about some function names / param orders as if it were the end of the world. I think a certain subset of people (shall we call them hipsters?) are just keen on finding new ground where they can rewrite the same boring things instead of working hard to improve the ecosystem of something existing. I moved on from PHP aeons ago because it got this undeserved bad rap, but I still follow it and would welcome the chance to run it again.

enraged_camel 7y ago
>> There was never anything wrong with PHP, really. I mean, your listed points are arguably correct, but this sentence is quite incorrect. edit: downvoted by PHP fans. It's OK, I get it, nobody likes it when others dunk on their favorite language. :)
- wk_end 7y ago
  You were downvoted because your post lacked any real content or rebuttal (and, probably, for the edit - no one likes it when people complain about downvotes). FWIW though, you're absolutely right - there was (maybe still is?) an enormous amount wrong with PHP. The only real rebuttal core-questions needs is a link to the classic essay, "PHP: a fractal of bad design" [1], which lists far, far more problems than just issues with function names or parameter order, and does it more comprehensively and with more style than you or I could hope to. [1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
  - arkh 7y ago
    One I always like is people using "mysql_real_escape_string". Well guess what? It comes from mysql itself: https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-string.html https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-st...
    - johannes1234321 7y ago
      Lots of "classic" PHP is just thin wrappers of C libraries. Many of the inconsistencies in PHP come from being consistent with those libraries.
      - tambourine_man 7y ago
        Not really. You may be surprised to learn, as I was, that PHP function hashing mechanism was strlen() in the beginning. So the number of characters was more important than naming consistency. https://news-web.php.net/php.internals/70691 https://news-web.php.net/php.internals/70691
        johannes1234321 7y ago
        That is for function with no C counterparts. htmlspecialchars() exists in no common C library. The reason strlen() is called strlen() (not string_length() or length() or whatever) however is due to C.
        lioeters 7y ago
        Yes, I was shocked to learn this about early PHP, that function names were hashed simply by their lengths - so names were chosen to fit a specific length. Pragmatic and fast? Yes. Insane design? Completely. Edit: I can also imagine this design decision must have had context. Perhaps it was a common technique in low-level programming, as a practical way to save time/space.
        johannes1234321 7y ago
        Given the amount of functions in early PHP (we are talking PHP/FI 2 max here, even userlevel code hardly had functions back then) even not hashing them at all, but doing a linear search over the function table would have been acceptable. Hashing by length most likely lead to few buckets with more than 3 functions.
- toxican 7y ago
  Dunk? What you've done is stood on the other end of the court, holding the ball and said "I can dunk this ball" then left the court. If you've got some counterpoints or arguments, please give them. Going "lol php bad" is just dumb.
dehrmann 7y ago
> No problem running it completely stateless It's a problem for some use cases, and even in the web use case, reusing connections to databases and services can be a pain with PHP because it's completely stateless.
- wolco 7y ago
  Persistent connections are available and if your connection dies the db request will continue next time the page is hit. Although that could cause more slowness issues.
- jawngee 7y ago
  > reusing connections to databases pgBouncer and ProxySQL are going to give you a better bang for the buck than a stateful web app will.
  - dijit 7y ago
    Maybe. Kinda. Not really. You can have an awful implementation of a connection pooler, sure, but opening an authenticated socket is more expensive by far than just referencing one. Less so for a unix socket/named pipe- but still much slower than a memory lookup. Of course you probably don’t care until you hit a certain scale or number of backend system accesses.
    - johannes1234321 7y ago
      Fetching a connection from a (sane) pool isn't just a memory lookup. Database conenctions have to be cleared of state (transactions, temp tables, prepared statement handles, ...) which takes time as well. Otherwise one runs into "funny" bugs at some point in time.
  - dehrmann 7y ago
    Unless they're local (and managing that fleet would get pretty annoying), there's still unnecessarily TCP overhead, and even the possibility of exhausting ports. I'm not arguing for a truly stateful webapp, but the connecting pooling you get for free (or some library wrangling) with a long-lived process does a lot for performance and scalability.
celticmusic 7y ago
It was more about certain communities highly valuing "prettiness", such as RoR.
- mtrpcic 7y ago
  To be fair, there is something to be said about the aesthetics of a language, and Ruby is (at least to me) a far more readable and "pretty" language than PHP. There are a lot of small niceties that, once you are familiar with them, make Ruby genuinely enjoyable to read.
  - tasogare 7y ago
    Yes, once you are familiar with. Otherwise, PHP with its generic curly-brace syntax is way easier to grok (I have to work on a codebase in Ruby and the funny syntax + no strongly typed compilation pass makes it really hard for me to get started modifying things).
  - jsjohnst 7y ago
    > and Ruby is (at least to me) a far more readable It’s funny folks pick on the “Magic” in PHP, yet overlook all of it in Ruby. I’m not a PHP guy anymore really (now Python/Rust/Java/Ruby mainly), but I’m still continually annoyed reading Ruby code. Here’s an example: - find a method being called on a class, so want to find out details on said method - grep through codebase, find no definition for said method - grep through all gem dependencies, find no definition for said method - search web, don’t find any obvious leads - cry in despair - finally find that method is handled by a method_missing on a dynamically generated class and never has anything related to the method name even as a string - flip desk and go home for the day
    - joelbluminator 7y ago
      Meta programming became far less common in Ruby, I barely see it in Rails apps anymore.
- ksec 7y ago
  This. And I do agree with all the point parent mentioned about PHP, it is just now I am a lot older I am starting to question this higher value of "prettiness".
BiteCode_dev 7y ago
I started my career as a php dev 15 years ago, and yes, there was plenty of wrong with php. Messy Api, terrible default, wonky typing, no namespace, etc. It succeeded, as it's often the case in IT, not because it was the best, or even very good, but because it was easy to adopt and had a killer feature.
- lucideer 7y ago
  > there was plenty of wrong with php. Messy Api, terrible default, wonky typing, no namespace, etc. "Messy Api" is discussed above ("it came down to people complaining about some function names / param orders as if it were the end of the world") so I won't comment. "terrible default": would be interested in specifics here "wonky typing": every scripting language had wonky typing 15 years ago, and many of them still do today. This has never been a valid criticism of PHP when comparing to it's primary competitors. "no namespace": THIS is a very valid criticism. PHP really wasn't a sane language before they added namespaces. But... they added namespaces 11 years ago.
  - imron 7y ago
    > would be interested in specifics here Magic quotes would be the first one I can think of off the top of my head, which incidentally, was made a default because the mysql api in PHP was so prone to sql injections, that PHP decided to automatically escape all user input as a way to protect inexperienced programmers. Pretty much everyone agrees magic quotes were a bad idea and they were eventually deprecated in 5.3 and removed entirely in 5.4.
  - hrktb 7y ago
    "Messy Api" isn't just parameters. For instance "Fatal" errors and regular errors going to two different logs was very messy and would byte you if you didn't pay special attention to it. Or multi-byte compliant methods that are a variants, and not the standard method, thus biting anyone who just thought utf-8 would be default. "terrible default": the poster child for this is register globals, which it took ages to have off by defaults. That's just a single line to set it properly, but that was part of the boilerplate that could have been avoided way earlier. Overall developing for PHP meant to defensively remember a ton a weird stuff, just like javascript was for a while. I am so glad we mostly got past that, even if I am not in PHP anymore.
pmlnr 7y ago
> There was never anything wrong with PHP, really. Looking at the Python standard libs vs the PHP standard libs, PHP used to be a bad mess. Other than that, it's still brilliant.
ferzul 7y ago
Php has had some really poor errorhandling and lots of magic. The idea that good error handing is just ignoring it is so wrong, that every update to php is basically a list of “this error will now be presented to you”. How many scripts continue to prohibit apostrophes in passwords because there used no way to reliably instruct devs on how to handle apostrophes in strings? People named O'Brien still can't enter their names in forms and expect to get it back despite magic quotes being gone years ago. Nowadays, modern php is conservative but fine. But it was really a terrible choice in its early days, when every one of its selling points was a misfeature.
- jsjohnst 7y ago
  > How many scripts continue to prohibit apostrophes in passwords because there used no way to reliably instruct devs on how to handle apostrophes in strings? Thankfully this problem was solved back in 2004/2005, but unfortunately shitty code was already pervasive and the “right way” wasn’t heavily communicated enough.
- sinni800 7y ago
  I have a framework that has a database backend that relied on some default behaviour of count() where if you don't put in an array, it would just return 0 and not error. Broke in 7.x because it would now warn now... I don't remember what it returns now but that was a thing...
mantap 7y ago
Function names and parameter order matter. That is the difference between having to look something up in the documentation and not. Back in those days most text editors didn't have fancy autocompletion with parameter documentation, if you weren't sure about the order you might have to look it up in the documentation. Having a self-consistent API that was easy to remember was essential. Especially in a language with dynamic types! When I switched from PHP to Python it was an amazing, liberating feeling for me that I will never forget.
- stef25 7y ago
  It takes 10 sec to google "str_replace" and have the params presented to you. Using a manual is an integral part of development. I don't think there's many people who can memorize all the methods and their params, including optional ones, nor should they.
  - cultus 7y ago
    That sounds like it takes a lot more time and mental energy than if the API were consistent.
    - Piskvorrr 7y ago
      We have machines to do that for us. As in, "press Ctrl+Q, IDE shows relevant help." I don't value encyclopedic knowledge of every API out there any more...especially since those I do recall are of rather, um, limited use nowadays. Like with any language, the point isn't to cram a dictionary into your brain, it's to communicate.
      - mantap 7y ago
        It's a red flag if the basic operations (like string and array functions) are so inconsistent and weird so as to require use of an IDE or constant use of the docs.
    - innocenat 7y ago
      Back in the day everyone has the PHP manual downloaded in CHM format (that was before broadband was common). Searching in CHM was just 1.5 seconds away.
tinus_hn 7y ago
PHP was the MySQL of programming languages and there was plenty wrong with it, mainly the dumb defaults that cause incessant security issues, all the inconsistencies and the habit of papering warnings over errors. This release is another step in resolving these problems.
- cowsandmilk 7y ago
  > the dumb defaults that cause incessant security issues The first Java web shop I worked for had a homegrown version of magic_quotes_gpc. That’s when I realized that those who had gone through making PHP installs and apps secure had very valuable experience.
  - sethammons 7y ago
    Interesting point! I learned a lot about security due to php. The problem was always that you don't know what you don't know. I recall going back to my first php site from like the php 3 days and I had zero SQL injection protection – I just didn't know it was a thing.
- jacob019 7y ago
  I think that is unfair to MySQL. MySQL is and always has been a fantastic piece of code and to my surprise it has developed and improved under Oracle's stewardship.
  - tinus_hn 7y ago
    PHP has always been a great piece of code as well, there clearly is a reason it is used so much. Like PHP, MySQL used to have stupid defaults though, like silently ignoring errors.
pjc50 7y ago
> Deploys are completely sane and predictable, it's just a bunch of files This was absolutely the killer app for PHP. It was lucky enough to be well integrated with Apache, and crucially could run as a non-persistent per-user interpreter behind the web server. This made it exactly ideal for deployment in shared hosting environments. The fact that you can't do this with e.g. Node forces all sorts of containerisation yak-shaving on us. People tried to do this with a few other languages, such as Apache mod_perl, but PHP was the one that thousands of cheap shared hosting providers made available, letting people get started with web development.
flir 7y ago
> Like, it came down to people complaining about some function names / param orders as if it were the end of the world. Arrays go (needle, haystack). Strings go (haystack, needle). There might be a couple of exceptions but that's basically it.
- dgb23 7y ago
  Higher order functions are inconsistent as well. There are many more examples. The language feels (is?) patched together.
thinkindie 7y ago
the biggest point is that people are focussing too much on PHP own quirky edges but then are fine with other languages insanity (I'm looking at you javascript and python). PHP is not perfect and I'm pretty sure it's bad name comes from code written for wordpress or joomla or the guy that came before you than PHP itself. Otherwise I can't understand how Python or Javascript can get away with way worse issues.
- uryga 7y ago
  what python issues do you have in mind? the linguistic gotchas i can name off the top of my head are: - the way mutable default arguments are handled - the weird behavior of closures referencing loop variables - leaking variables out of if/for/with (yes, i know it's convenient, but can bite sometimes) - GIL stuff - exec not being able to introduce new local variables (yes, i know code-objects have their local variables decided at compile time, but it's surprising if you don't care about that implementation detail) other than that i can't think of many "insane" behaviors that can bite you. i'm curious what you're referring to! and sure, i'd change a lot of the language to make it more FP-friendly if i could, but being what it is, the semantics seem pretty unsurprising most of the time
  - rvnx 7y ago
    Isn't the base indentation style of Python insane ? I remove a "if:" block and and have to press backspace, maybe 100 times ? If I add one "if:" then have to press 100 times on space ? Yes, nice you can have Python-adapted editors where ident levels can be tuned, but no, it's still a big defect
    - eru 7y ago
      No, the indentation is a feature. Your editor can help you with the editing. (And the problem you mention are exactly the same, if you write production code in other language. Your teammates will hopefully insist on consistent indentation in C or Java as well.)
    - uryga 7y ago
simias 7y ago
It's fine to like PHP and I'm willing to believe that modern PHP is a lot better than what it used to be but it annoys me that every time the language is brought up these days some people feel like rewriting history to pretend that PHP-bashing 15years ago was just a baseless memes made by haters who didn't get it. There was plenty of wrong with PHP. There were very unsafe defaults, poor API choices, poor coding standards, inconsistent syntax, paper-thin C bindings that didn't provide the level of abstraction you'd expect from a scripting language etc... If you've forgotten what PHP used to be you can just take a trip down memory lane by browsing through this classic: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ . Lest we forget PHP was started as a templating engine that evolved haphazardly into a full fledged programming language, and it showed. If you think PHP is a good language today then say that, but let's not pretend that the complaints and ridicule were always undeserved.
- burnte 7y ago
  > If you think PHP is a good language today then say that, but let's not pretend that the complaints and ridicule were always undeserved. It's a question of when do you let that go?
  - kossae 7y ago
    Right, I don't think it's necessarily the people that are _for_ PHP are ignoring the past, it's that the people _against_ PHP are still stuck in it.
    - slikts 7y ago
      This is a common straw man; PHP 5 and 7 made large strides, but that's because there was so much to fix, and there still is and will continue to be, like lack of first class functions, actual modules, etc. PHP is also unsuitable for persistent processes like serving WebSocket.
      - DJBunnies 7y ago
eru 7y ago
Compare https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ which is not really about the strawmen you mention.
- Piskvorrr 7y ago
  2012. I did agree with it wholeheartedly, when it came out and PHP 5.3 was brand new. It is now 8 years and several major versions later, most of the critique is obsolete and the rest is just "let me try to write horrible code; see, PHP is horrible because it's written in PHP!"
  - eru 7y ago
    The comment I replied to said: 'There was _never_ anything wrong with PHP, really.' (Emphasis mine.) Btw, I do agree with most of the changes Facebook's Hack made to PHP.
    - Piskvorrr 7y ago
      Oh, ok. There was an immense number of things wrong with PHP. It's gotten to the usual manageable level of $anylanguage.
ryanmccullagh 7y ago
I've been working on a dead simple service to deploy and host Laravel/PHP applications without having to do system administration. https://www.amezmo.com https://www.amezmo.com

enraged_camel 7y ago

>> There was never anything wrong with PHP, really. I mean, your listed points are arguably correct, but this sentence is quite incorrect. edit: downvoted by PHP fans. It's OK, I get it, nobody likes it when others dunk on their favorite language. :)

wk_end 7y ago
You were downvoted because your post lacked any real content or rebuttal (and, probably, for the edit - no one likes it when people complain about downvotes). FWIW though, you're absolutely right - there was (maybe still is?) an enormous amount wrong with PHP. The only real rebuttal core-questions needs is a link to the classic essay, "PHP: a fractal of bad design" [1], which lists far, far more problems than just issues with function names or parameter order, and does it more comprehensively and with more style than you or I could hope to. [1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
- arkh 7y ago
  One I always like is people using "mysql_real_escape_string". Well guess what? It comes from mysql itself: https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-string.html https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-st...
  - johannes1234321 7y ago
    Lots of "classic" PHP is just thin wrappers of C libraries. Many of the inconsistencies in PHP come from being consistent with those libraries.
    - tambourine_man 7y ago
      Not really. You may be surprised to learn, as I was, that PHP function hashing mechanism was strlen() in the beginning. So the number of characters was more important than naming consistency. https://news-web.php.net/php.internals/70691 https://news-web.php.net/php.internals/70691
      - johannes1234321 7y ago
        That is for function with no C counterparts. htmlspecialchars() exists in no common C library. The reason strlen() is called strlen() (not string_length() or length() or whatever) however is due to C.
      - lioeters 7y ago
        Yes, I was shocked to learn this about early PHP, that function names were hashed simply by their lengths - so names were chosen to fit a specific length. Pragmatic and fast? Yes. Insane design? Completely. Edit: I can also imagine this design decision must have had context. Perhaps it was a common technique in low-level programming, as a practical way to save time/space.
        johannes1234321 7y ago
        Given the amount of functions in early PHP (we are talking PHP/FI 2 max here, even userlevel code hardly had functions back then) even not hashing them at all, but doing a linear search over the function table would have been acceptable. Hashing by length most likely lead to few buckets with more than 3 functions.
toxican 7y ago
Dunk? What you've done is stood on the other end of the court, holding the ball and said "I can dunk this ball" then left the court. If you've got some counterpoints or arguments, please give them. Going "lol php bad" is just dumb.

dehrmann 7y ago

> No problem running it completely stateless It's a problem for some use cases, and even in the web use case, reusing connections to databases and services can be a pain with PHP because it's completely stateless.

wolco 7y ago
Persistent connections are available and if your connection dies the db request will continue next time the page is hit. Although that could cause more slowness issues.
jawngee 7y ago
> reusing connections to databases pgBouncer and ProxySQL are going to give you a better bang for the buck than a stateful web app will.
- dijit 7y ago
  Maybe. Kinda. Not really. You can have an awful implementation of a connection pooler, sure, but opening an authenticated socket is more expensive by far than just referencing one. Less so for a unix socket/named pipe- but still much slower than a memory lookup. Of course you probably don’t care until you hit a certain scale or number of backend system accesses.
  - johannes1234321 7y ago
    Fetching a connection from a (sane) pool isn't just a memory lookup. Database conenctions have to be cleared of state (transactions, temp tables, prepared statement handles, ...) which takes time as well. Otherwise one runs into "funny" bugs at some point in time.
- dehrmann 7y ago
  Unless they're local (and managing that fleet would get pretty annoying), there's still unnecessarily TCP overhead, and even the possibility of exhausting ports. I'm not arguing for a truly stateful webapp, but the connecting pooling you get for free (or some library wrangling) with a long-lived process does a lot for performance and scalability.

celticmusic 7y ago

It was more about certain communities highly valuing "prettiness", such as RoR.

mtrpcic 7y ago
To be fair, there is something to be said about the aesthetics of a language, and Ruby is (at least to me) a far more readable and "pretty" language than PHP. There are a lot of small niceties that, once you are familiar with them, make Ruby genuinely enjoyable to read.
- tasogare 7y ago
  Yes, once you are familiar with. Otherwise, PHP with its generic curly-brace syntax is way easier to grok (I have to work on a codebase in Ruby and the funny syntax + no strongly typed compilation pass makes it really hard for me to get started modifying things).
- jsjohnst 7y ago
  > and Ruby is (at least to me) a far more readable It’s funny folks pick on the “Magic” in PHP, yet overlook all of it in Ruby. I’m not a PHP guy anymore really (now Python/Rust/Java/Ruby mainly), but I’m still continually annoyed reading Ruby code. Here’s an example: - find a method being called on a class, so want to find out details on said method - grep through codebase, find no definition for said method - grep through all gem dependencies, find no definition for said method - search web, don’t find any obvious leads - cry in despair - finally find that method is handled by a method_missing on a dynamically generated class and never has anything related to the method name even as a string - flip desk and go home for the day
  - joelbluminator 7y ago
    Meta programming became far less common in Ruby, I barely see it in Rails apps anymore.
ksec 7y ago
This. And I do agree with all the point parent mentioned about PHP, it is just now I am a lot older I am starting to question this higher value of "prettiness".

BiteCode_dev 7y ago

I started my career as a php dev 15 years ago, and yes, there was plenty of wrong with php. Messy Api, terrible default, wonky typing, no namespace, etc. It succeeded, as it's often the case in IT, not because it was the best, or even very good, but because it was easy to adopt and had a killer feature.

lucideer 7y ago
> there was plenty of wrong with php. Messy Api, terrible default, wonky typing, no namespace, etc. "Messy Api" is discussed above ("it came down to people complaining about some function names / param orders as if it were the end of the world") so I won't comment. "terrible default": would be interested in specifics here "wonky typing": every scripting language had wonky typing 15 years ago, and many of them still do today. This has never been a valid criticism of PHP when comparing to it's primary competitors. "no namespace": THIS is a very valid criticism. PHP really wasn't a sane language before they added namespaces. But... they added namespaces 11 years ago.
- imron 7y ago
  > would be interested in specifics here Magic quotes would be the first one I can think of off the top of my head, which incidentally, was made a default because the mysql api in PHP was so prone to sql injections, that PHP decided to automatically escape all user input as a way to protect inexperienced programmers. Pretty much everyone agrees magic quotes were a bad idea and they were eventually deprecated in 5.3 and removed entirely in 5.4.
- hrktb 7y ago
  "Messy Api" isn't just parameters. For instance "Fatal" errors and regular errors going to two different logs was very messy and would byte you if you didn't pay special attention to it. Or multi-byte compliant methods that are a variants, and not the standard method, thus biting anyone who just thought utf-8 would be default. "terrible default": the poster child for this is register globals, which it took ages to have off by defaults. That's just a single line to set it properly, but that was part of the boilerplate that could have been avoided way earlier. Overall developing for PHP meant to defensively remember a ton a weird stuff, just like javascript was for a while. I am so glad we mostly got past that, even if I am not in PHP anymore.

pmlnr 7y ago

> There was never anything wrong with PHP, really. Looking at the Python standard libs vs the PHP standard libs, PHP used to be a bad mess. Other than that, it's still brilliant.

ferzul 7y ago

Php has had some really poor errorhandling and lots of magic. The idea that good error handing is just ignoring it is so wrong, that every update to php is basically a list of “this error will now be presented to you”. How many scripts continue to prohibit apostrophes in passwords because there used no way to reliably instruct devs on how to handle apostrophes in strings? People named O'Brien still can't enter their names in forms and expect to get it back despite magic quotes being gone years ago. Nowadays, modern php is conservative but fine. But it was really a terrible choice in its early days, when every one of its selling points was a misfeature.

jsjohnst 7y ago
> How many scripts continue to prohibit apostrophes in passwords because there used no way to reliably instruct devs on how to handle apostrophes in strings? Thankfully this problem was solved back in 2004/2005, but unfortunately shitty code was already pervasive and the “right way” wasn’t heavily communicated enough.
sinni800 7y ago
I have a framework that has a database backend that relied on some default behaviour of count() where if you don't put in an array, it would just return 0 and not error. Broke in 7.x because it would now warn now... I don't remember what it returns now but that was a thing...

mantap 7y ago

Function names and parameter order matter. That is the difference between having to look something up in the documentation and not. Back in those days most text editors didn't have fancy autocompletion with parameter documentation, if you weren't sure about the order you might have to look it up in the documentation. Having a self-consistent API that was easy to remember was essential. Especially in a language with dynamic types! When I switched from PHP to Python it was an amazing, liberating feeling for me that I will never forget.

stef25 7y ago
It takes 10 sec to google "str_replace" and have the params presented to you. Using a manual is an integral part of development. I don't think there's many people who can memorize all the methods and their params, including optional ones, nor should they.
- cultus 7y ago
  That sounds like it takes a lot more time and mental energy than if the API were consistent.
  - Piskvorrr 7y ago
    We have machines to do that for us. As in, "press Ctrl+Q, IDE shows relevant help." I don't value encyclopedic knowledge of every API out there any more...especially since those I do recall are of rather, um, limited use nowadays. Like with any language, the point isn't to cram a dictionary into your brain, it's to communicate.
    - mantap 7y ago
      It's a red flag if the basic operations (like string and array functions) are so inconsistent and weird so as to require use of an IDE or constant use of the docs.
  - innocenat 7y ago
    Back in the day everyone has the PHP manual downloaded in CHM format (that was before broadband was common). Searching in CHM was just 1.5 seconds away.

tinus_hn 7y ago

PHP was the MySQL of programming languages and there was plenty wrong with it, mainly the dumb defaults that cause incessant security issues, all the inconsistencies and the habit of papering warnings over errors. This release is another step in resolving these problems.

cowsandmilk 7y ago
> the dumb defaults that cause incessant security issues The first Java web shop I worked for had a homegrown version of magic_quotes_gpc. That’s when I realized that those who had gone through making PHP installs and apps secure had very valuable experience.
- sethammons 7y ago
  Interesting point! I learned a lot about security due to php. The problem was always that you don't know what you don't know. I recall going back to my first php site from like the php 3 days and I had zero SQL injection protection – I just didn't know it was a thing.
jacob019 7y ago
I think that is unfair to MySQL. MySQL is and always has been a fantastic piece of code and to my surprise it has developed and improved under Oracle's stewardship.
- tinus_hn 7y ago
  PHP has always been a great piece of code as well, there clearly is a reason it is used so much. Like PHP, MySQL used to have stupid defaults though, like silently ignoring errors.

pjc50 7y ago

> Deploys are completely sane and predictable, it's just a bunch of files This was absolutely the killer app for PHP. It was lucky enough to be well integrated with Apache, and crucially could run as a non-persistent per-user interpreter behind the web server. This made it exactly ideal for deployment in shared hosting environments. The fact that you can't do this with e.g. Node forces all sorts of containerisation yak-shaving on us. People tried to do this with a few other languages, such as Apache mod_perl, but PHP was the one that thousands of cheap shared hosting providers made available, letting people get started with web development.

flir 7y ago

> Like, it came down to people complaining about some function names / param orders as if it were the end of the world. Arrays go (needle, haystack). Strings go (haystack, needle). There might be a couple of exceptions but that's basically it.

dgb23 7y ago
Higher order functions are inconsistent as well. There are many more examples. The language feels (is?) patched together.

thinkindie 7y ago

the biggest point is that people are focussing too much on PHP own quirky edges but then are fine with other languages insanity (I'm looking at you javascript and python). PHP is not perfect and I'm pretty sure it's bad name comes from code written for wordpress or joomla or the guy that came before you than PHP itself. Otherwise I can't understand how Python or Javascript can get away with way worse issues.

uryga 7y ago
what python issues do you have in mind? the linguistic gotchas i can name off the top of my head are: - the way mutable default arguments are handled - the weird behavior of closures referencing loop variables - leaking variables out of if/for/with (yes, i know it's convenient, but can bite sometimes) - GIL stuff - exec not being able to introduce new local variables (yes, i know code-objects have their local variables decided at compile time, but it's surprising if you don't care about that implementation detail) other than that i can't think of many "insane" behaviors that can bite you. i'm curious what you're referring to! and sure, i'd change a lot of the language to make it more FP-friendly if i could, but being what it is, the semantics seem pretty unsurprising most of the time
- rvnx 7y ago
  Isn't the base indentation style of Python insane ? I remove a "if:" block and and have to press backspace, maybe 100 times ? If I add one "if:" then have to press 100 times on space ? Yes, nice you can have Python-adapted editors where ident levels can be tuned, but no, it's still a big defect
  - eru 7y ago
    No, the indentation is a feature. Your editor can help you with the editing. (And the problem you mention are exactly the same, if you write production code in other language. Your teammates will hopefully insist on consistent indentation in C or Java as well.)
  - uryga 7y ago

simias 7y ago

It's fine to like PHP and I'm willing to believe that modern PHP is a lot better than what it used to be but it annoys me that every time the language is brought up these days some people feel like rewriting history to pretend that PHP-bashing 15years ago was just a baseless memes made by haters who didn't get it. There was plenty of wrong with PHP. There were very unsafe defaults, poor API choices, poor coding standards, inconsistent syntax, paper-thin C bindings that didn't provide the level of abstraction you'd expect from a scripting language etc... If you've forgotten what PHP used to be you can just take a trip down memory lane by browsing through this classic: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ . Lest we forget PHP was started as a templating engine that evolved haphazardly into a full fledged programming language, and it showed. If you think PHP is a good language today then say that, but let's not pretend that the complaints and ridicule were always undeserved.

burnte 7y ago
> If you think PHP is a good language today then say that, but let's not pretend that the complaints and ridicule were always undeserved. It's a question of when do you let that go?
- kossae 7y ago
  Right, I don't think it's necessarily the people that are _for_ PHP are ignoring the past, it's that the people _against_ PHP are still stuck in it.
  - slikts 7y ago
    This is a common straw man; PHP 5 and 7 made large strides, but that's because there was so much to fix, and there still is and will continue to be, like lack of first class functions, actual modules, etc. PHP is also unsuitable for persistent processes like serving WebSocket.
    - DJBunnies 7y ago

eru 7y ago

Compare https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ which is not really about the strawmen you mention.

Piskvorrr 7y ago
2012. I did agree with it wholeheartedly, when it came out and PHP 5.3 was brand new. It is now 8 years and several major versions later, most of the critique is obsolete and the rest is just "let me try to write horrible code; see, PHP is horrible because it's written in PHP!"
- eru 7y ago
  The comment I replied to said: 'There was _never_ anything wrong with PHP, really.' (Emphasis mine.) Btw, I do agree with most of the changes Facebook's Hack made to PHP.
  - Piskvorrr 7y ago
    Oh, ok. There was an immense number of things wrong with PHP. It's gotten to the usual manageable level of $anylanguage.

ryanmccullagh 7y ago

I've been working on a dead simple service to deploy and host Laravel/PHP applications without having to do system administration. https://www.amezmo.com https://www.amezmo.com