Why Developers Hate PHP | Hacker News Reader

Why Developers Hate PHP

jesuisundev.com

66 pointsjesuisundev111 comments

> Most developers who hate PHP hate it out of elitism or ignorance. Either way it’s dumb. You have to choose a technology based on what you need. PHP is highly useful and powerful in many scenarios. And taking it out of the equation just because of its reputation is not a good idea.

When I conduct hiring interviews, one of the questions I like to ask regardless of the language for the position, is the developer opinion on PHP.

It's not uncommon for some to start massive rant based on outdated or outright wrong statements about PHP. Most of them never even used PHP.

It's a nice question to filter out elitists. The best candidates usually answer either "can't say because I have never used PHP" or state pros and cons of PHP based on their experience.

edit: quick -3 downvotes. I suspect I hit a nerve in some elitists who would not get that Rust or Haskell position because they would have baselessly trashtalked PHP in my interviews.

They might think you expect them to dislike it. Also, maybe they fear if they say they like PHP you'll take points off.

That goes for any question in interviews. I expect honesty and I'm straightforward about it.

This is not really a question like any other, because it's a very polarizing one.

It's fair to intentionally ask polarizing questions if the objective is to find how if a candidate can take moderate positions in those contexts, but it's definitely not like "any question in interviews".

Fair enough. It's not comparable to just any question. But hear me, you have to poke the bee's nest with some polarizing questions to really know what's inside otherwise you're stuck hiring an unknown until it's too late and costly (for both parties) to find out they were not a good match.

I'm not saying don't ask it. If anything it can reveal personality issues like any question. Just saying as a statistic it's not reliable. :P

> It's not uncommon for some to start massive rant based on outdated or outright wrong statements about PHP.

If they make wrong statements, I agree, they shouldn't do that.

If they make outdated statements... well, what would you expect from someone who used PHP in the past and then stopped using it? Do you expect people to stay up-to-date on a language they no longer use? If so, why, and can you think of reasons they wouldn't?

It's not a boolean judgement for sure. There's a spectrum between hating a technology for the sake of it (elitists) and just stating outdated info about a technology which is passable.

As with any interview, one question alone rarely filters out candidates. They weight on the result.

PHP always struck me as a language that had very haphazard beginnings and initial design considerations that continue to cause it problems, but less so as time goes one, that has made mostly good and well thought out decisions since then (and possibly because of that).

The base language functions are a train wreck of multiple functions doing similar things that could easily be handled through a few slightly more flexible functions (e.g. the numerous array specific functions), and there's little consistency between types and orders of arguments in the base functions of the language, but the class and object system seemed very sane and easy to work with as of somewhere in the 5.x timeline, especially compared to Python and Perl. I haven't used it much since about 2011, but I imagine it's better since then, not worse.

> It's not uncommon for some to start massive rant based on outdated or outright wrong facts about PHP. Most of them never even used PHP. It's a nice question to filter out elitists.

Even with all I said above, I think you might also be filtering out some people with a little bit of PTSD instead of elitists (but that might not be a bad thing for hiring). A lot of people started with PHP and might have moved to other languages when they became upset with some of it's real deficiencies, when those deficiencies composed a larger portion of the language then they do now.

There's a world of difference between starting a new project in a language using newer features and libraries in that language and maintaining some monstrosity from a decade or more ago, which some of these people may have been caught up in.

I'm a Perl developer myself, and when I have to work on 10-20 year old Perl code (or new projects where I feel we haven't adapted to all the newer things we could so we're forced into paradigms that are dated), it can feel very painful and disheartening, like you're standing in place and the world is moving around you. Too much bleeding edge is bad from a reliability standpoint, but too much stagnation is bad from a developer mindset standpoint. Both have their own business costs.

You're right. And if you told me anything along those lines during an interview I would smile wide open knowing you speak from experience and not from prejudice.

Yeah, it's actually a pretty good method to get a feel for people, in my mind. There's a lot of red flags it can expose.

Someone that rabidly comes to the defense of PHP in an overly negative way towards others will also probably raise red flags, and the people that are prejudiced against PHP but at least smart enough not to put their their mouths when talking to others come across better, which they probably should, since team relations/compatibility is also often an important part hiring.

It's hiring, which is just hard. Give the candidates enough tests to generate as much useful data as possible, and then make some gut decision you hope is based on real indicators and not your own biases, and hope for the best. :)

> there's little consistency between types and orders of arguments in the base functions of the language

This is an inheritance from C. Most of these functions are present in libc and the bound libraries (e.g. libcurl), with the same arguments. 20something years ago, this was a big selling point to me, because I didn't have to re-learn the functions, just use the function and forget about malloc()/free()...

This clearly shows PHP's origin as a set of loosely related libraries and utilities ties together with a thin veneer of a language. When used as an actual language it's less than ideal. Who's to say curl will still be the default way it makes some requests in the core language later? What if the library changes it's API after deprecating the version that was originally used? Coupling things like that is a poor design choice (unless the thing you're matching is a standard, that's less likely to change in backwards incompatible ways, at least without plans for how to deal with it).

It was a benefit to those that knew C and worked with the same libs there, and it was easier for early PHP developers to include stuff (since they didn't have to develop a separate API and abstract usage), but it definitely contributed to PHP's reputation of being hard to intuit how a function expected to be used.

You can compare and contrast this to Perl, where for the most part they didn't include C libraries in the core (generally they were done as modules, and there are modules that emulate C's calling methods exactly, and those that provide an extrapolated API, sometimes from the base library, sometimes building on the other module), but they did include a lot of the C standard library functions in familiar usage patters, but still altered to fit the design goals and ideas Perl was being developed with (Perl is a highly designed language, it's just that its design goals often make it look haphazard to those that haven't internalized them).

Both approaches have their strengths and weaknesses. I would say PHP's approach was useful very early on, but quickly became detrimental for most users (it was useful longer for devs I imagine), but PHP's other strengths helped mitigate that (IMO, being able to be built into Apache in a manner other languages couldn't imitate well was a killer feature for a long time).

Indeed, but modern frameworks get around this quickly. If you use Symfony, Laravel or Drupal, you will likely never use these functions, because they are packaged as a replaceable module with proper OOP interfaces and classes.

Most people who pick PHP these days are doing that because these very mature frameworks. I see no alternative to Drupal with all its glory in any of the modern languages.

I think PHP-s success was related to its relative low latency compared the early Ruby and Perl, especially when FCGI became supported. We could easily serve 200+ interactive websites on a single desktop PC, with five-nines SLO.

Sure, there are much better, more fun languages these days, but to retire PHP we need to find better worthy FOSS alternatives to the PHP CMS-es.

I don't necessarily think PHP needs to be retired. It's obviously matured and has plenty of use. I was just pointing out the flip side to using similar functions to the underlying C libs.

I've come to view languages as a set of competing trade-offs that optimize for specific points in it's life-cycle, whether purposefully or accidentally. For example, Python's "batteries included" feature was extremely useful early on. Now a lot of the included modules are superseded by a better external module that's the de-facto standard. For example, the Requests library for Python. Originally batteries included was a feature, but now certain modules in the standard library are mostly useful for backwards compatibility and do little otherwise except confuse new Python programmers.

Perl went through the same with the CGI module, which was old, crufty, had an interface that made it hard to keep contained, and was almost universally considered a bad idea (except for when you needed it for backwards compatibility, or really actually needed a CGI). It was eventually excised from the standard library, and relegated to an external library, so the Perl core didn't have to worry about it and it wasn't considered the default method for created web pages in Perl.

And that's just one axis. There's also optimizing for ease of use for amateurs (i.e. ease of learning) or ease of use for laymen/professionals. One makes it harder to get new users, the other often makes it harder to retain existing users (because what a layman wants is often not the same as what an amateur wants). You could consider APL to be at an extreme end of this spectrum. I imagine APL laymen are happy with the concise format and features because they've developed the skills to accurately read and interpret APL programs. As someone that doesn't know APL (as amateur as you can get), it's extremely daunting to see.

Then there's verbosity vs conciseness. And any number of other aspects of a language. Each is usually imparting some specific aspect to the language, and isn't necessarily better or worse than the same aspect of different languages, but often just optimized for something different.

its fun to trash talk PHP who cares if statements are accurate. PHP sucks because of the dollar signs everywhere. From a distance Wordpress code looks like Nigerian Prince emails.

And crazy coding conventions like mysql_real_escape_string. Really PHP?

> From a distance Wordpress code looks like Nigerian Prince emails. And crazy coding conventions like mysql_real_escape_string. Really PHP

This is good stuff. And correct. I'd love to hear that during an interview. Although mysql_real_escape_string() is not really used anymore nor condoned last I checked.

> PHP sucks because of the dollar signs everywhere

Now this is just an opinion. No bueno my friend.

Actually, what I dislike about PHP's dollar signs is that the make it look like Perl, but they are tacked on to lists and hashes also.

I suspect the dollar signs may be part of the reason of PHP's success. While it's clear for experienced programmers that "x" and "y" are variables and "foo" is a function in "x = foo(y)", for new programmers "$x = foo($y)" is probably easier to read and mentally parse.

That is my personal experience anyway, as someone whose first truly serious language was PHP 20 years ago. Maybe it was just because I was used to it (BASIC also used $), but it took me a bit to get used to the "bare" variables in Python and C back in the day.

mysql_real_escape_string() comes from the MySQL C library binding: https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-st...

this actually makes sense. Maybe I was wrong about PHP. But maybe not :)

Did PHP ever decide whether NULL < -1 or NULL == 0? I want to hire people who care about correctness, and insanity like that really should bother them.

null == 0 is true.

null === 0 is false.

false == 0 is true.

false === 0 is false.

null == false is true.

null === false is false.

null < -1 is true.

Like in JavaScript, just don't use ==. It's broken but you don't have to use it.

In C you can write i[t] instead of t[i], but don't do it.

I guess it's true for many languages. These funny features don't prevent you from writing good code, especially if you enforce some coding styles that will catch any unintended use of these features.

Blame PHP for what you can't do with it, or for things you don't like but are forced to do. For instance I like PHP but I cannot type things the way I'd like. It's getting better though.

I don't like the inconsistencies in the function names of the standard library but the functions are often straightforward and very simple to use. And, above all, the doc is good. These aspects mean I don't waste time figuring out how to do simple things because of a complex interface involving many classes, despite the inconsistencies.

I also don't like the dollar notation for variables but that's a matter of taste, nor the syntax for namespaces, nor the implicit declaration of variables (like in Python by the way).

> In C you can write i[t] instead of t[i], but don't do it.

I had to check this myself. I'm astonished.

C array access syntax is just syntactic sugar for pointer arithmetic. The array decays to a pointer so `t[i]` is interpreted as:

    *(t + i)

So you can see how swapping that around to `i[t]` is effectively the same operation:

    *(i + t)

are you sure null < -1 is true? If it's the case what happens to 0 < -1?

Well, -1 is just 0x…FFFFF, right? So any number is lesser than -1. I rest my case.

To test all cases and make sure there there isn't any weird cases (Run on PHP 7.2):

<?php

if (null > -1) { echo "null > -1\n"; }

if (null < -1) { echo "null < -1\n"; }

if (null == -1) { echo "null == -1\n"; }

if (null === -1) { echo "null === -1\n"; }

if (0 < -1) { echo "0 < -1\n"; }

if (0 > -1) { echo "0 > -1\n"; }

if (0 == -1) { echo "0 == -1\n"; }

if (0 === -1) { echo "0 === -1\n"; }

results:

null < -1

0 > -1

Output for 4.3.0 - 7.4.6

   null == 0 is true
   null === 0 is false
   false == 0 is true
   false === 0 is false
   null == false is true
   null === false is false
   null < -1 is true

https://3v4l.org/UJ3tm

PHP has its pros and cons. A big pro is definitively job security: learn it now, learn it well and you'll have work for quite a long time. Composer is a pretty sane package manager, there are tons of frameworks and libraries out there to do nearly anything you can imagine, and also it's surprisingly fast. I'll even forgive the operator weirdness-- one big pain point that remains for me is how debugging PHP code is done.

That said, after dealing with JavaScript and its inane ecosystem has made me appreciate all the ways in which PHP has improved over the years, although that's probably not the kind of answer you'd be looking for. :P

It's a sensible and valid answer that wouldn't raise any eyebrows on my part.

I think there's something people miss when looking at PHP as a system - the fact that it's a collection of hot swappable logic modules (pages)

PHP pages themselves can download packages of additional PHP pages and extend functionality as the website runs. For example the user can install a message board from the UI in WordPress, and PHP files themselves will download additional PHP files needed for a message board, and boom your site now has a message board - no recompile, install, or deploy. Your running system has extended itself in real-time with additional functionality.

Maybe I'm crazy, but I think there is something special about this that our typical compile/deployed applications aren't designed for.

Before the web, applications tended to carry their state in memory, but with the web we stored state in the database. Our logic really only needs to take the request from the user and either pull or modify data from the database and return. A lot of web apps today feel hollow as we rarely store state in them, we just pull, manipulate, and render database data. What if each major code path was its own binary? That's kind of like what PHP is.

With PHP the application is almost living as it is never really turned off/on, just modified over time. If there's a bug in one page, I just need to fix that one page. And a single page is lightning fast to deploy to my servers. The rest of the system keeps humming.

Now the language itself might not be the best, but do you see how this system is fundamentally different from single binary web applications?

There was a tech talk I saw on Youtube a few years ago that I really liked that argued that Facebook succeeded because of PHP, not despite it.

IIRC, the main argument was that despite its flaws, PHP has one killer feature, which is that it lets you have really tight iteration loops for web development. This made developing in PHP extremely productive.

I searched around for the video, but couldn't find it.

The type of developers FB wanted were already using PHP and that made it good fit

I know it's cool to hate PHP but I can think of other languages (Perl, VB6, Groovy) I dislike more. For a language to be so hated it has to be used a lot, and that's the primary virtue of PHP: it runs damn-near everywhere. Not only web scripting/apps but you can use it for shell scripting, Lambda/Azure Functions... there are even frameworks for creating native mobile applications with PHP. And I wouldn't be surprised if it compiles to JavaScript as well.

> For a language to be so hated it has to be used a lot, and that's the primary virtue of PHP: it runs damn-near everywhere.

“Runs damn-near everywhere” is true of nearly all contemporary scripting languages, though, no? It’s definitely used a lot, though I don’t know how that compares to Perl, Ruby, Python... Without digging in harder, I still think it came at about the right time and had a killer feature: a dynamic nascent web with an incredibly low barrier to entry. You could create a form and ask for a persons name and have it respond “Hello, $name!”. I feel like it got entrenched and never gave that up.

Yeah, I think that goes back to something the OP said, which is that it's a victim of its own success. It's old enough that everyone has had a bad experience with it. I've had many that are directly or indirectly tied to PHP - my college blog was a hodgepodge of unmaintainable PHP scripts, I've run Wordpress blogs with plugins that broke in horrible and confusing ways, some things like argument order and operator precedence are confusing.

Combine with a long-enough life to have some famous bugs (like the hash collision DOS attack), and you have a recipe for widespread derision.

But it kept getting better. I work in PHP at my day job, and I enjoy it. Tools like PhpStorm and Phan make the experience excellent. If PHP 7.4 were launched today as "AWSLang", a stateless object-oriented optionally-typed scripting language that seems designed for working with Lambda functions, we'd love it. "You mean it just dies at the end of the request by default? No shared mutable state between requests? How functional!" Sure, we'd have a few things to complain about. But don't we always?

That "article" spent half its time leading up to explaining why PHP is bad and half its height on GIANT MEMES. The actual content was half a paragraph about how PHP lacks strong conformity... needless waste of bits

I thought it was entertaining had a good bit of history. It does a good job of empathizing with the reader and then shedding light on why they might want to change their opinions on PHP.

Agreed, the author might have a good point but I really dislike this style of writing where I have to scroll through a few megabytes of animated image macros to get to the point.

These memes are always forced and never funny.

Here to see how many comments don't bother reading the piece and just react to the title.

I didn't, skimmed.

> PHP is the most widely used language in the world for websites.

Being served does not equate to being used to develop new things.

Is there really that many new websites, website features being authored in PHP? Sure there is maintenance work and some popular platforms are written in it. But beyond that? I haven't seen a job posting in long time.

There are plenty of job postings. They just mostly say stuff like "Laravel" instead of "PHP".

It consistently makes the list for any analysis of "top X languages by job posting" I can find.

I'm using it at a fresh start up. Having used node, internal Google frameworks, python, and dart previously, I would highly recommend PHP for new projects. Laravel is what makes it worth it imo.

Laravel is pretty sweet, I recently scoped it out (been in Flask land and itching to try some Elixir/Phoenix) and it's got everything, exploring the queues now. I really like the helpers for accessing array elements through dot notation. Example:

  $data = [
  'more' => [
      'complex' => ['my value']
   ]
  ];

  if (array_key_exists('more', $data) && array_key_exists('complex', $data['more']) && array_key_exists(0, $data['more']['complex'])) {
  echo $data['more']['complex'][0];
  }

You can do this:

  echo Arr::get($data, 'more.complex.0');

Plus the bog standard php null coalescing operator "??" is pretty sweet.

  // fetch the value of $_GET['user'] and returns 'not passed'
  // if username is not passed
  $username = $_GET['username'] ?? 'not passed';

Just some little things off the top of my head. *Formatting.

Arr::get($data, 'more.complex.0'); is much nicer, I agree.

I do think better languages do it better, for example in Elixir I can extract multiple elements out of an object at the same time.

  object = %{nested: ["my value"], other: "some element"}

  %{nested: [first | _], other: other} = object

first now equals "my value" and other now equals "some element".

PHP sucks because of the legacy it pulls with it that keeps it from being simple and elegant. It also fails pretty hard when you use it outside of it's niche, and a multi-purpose language > single purpose language.

Yeah, still just checking it out, getting an auth system working with oAuth in about 15 mins via Socialite was fun. I want to test out the Lambda deployment which seems sweet. I use Serverless for that ATM with JS and Python. Elixir pattern matching is fantastic and I miss being able to call functions by arity. I don't know which deployment process I prefer, yet. They all suck.

I don't understand this response. You are proud you didn't read the article? Does it add any value to the conversation to just pull out one sentence and react to it out of context?

The only thing I can think of is that HN rewards early responses with more karma, so people feel a need to rush past the "reading" and "thinking" parts and just skip to the "responding" part to rack up more internet points. Perhaps HN should look into ways to rework things to reduce or remove that incentive.

My company has switched to using it. The 7.x versions have really made PHP a much better experience. I still hate the inconsistent method names.

I write very little PHP but I work on a PHP extension written in C for a security product that integrates tightly with the language and some of the reasons I hate it are:

The Zend APIs suck, and they have non-existent or severely outdated docs. For example, one of PHP's main internal data structure, zend_hash, is a weird hash table with a string / int union key type and is awkward to access or iterate over.

Memory issues. I've had to debug segfaults caused by memory bugs in the language and core libs more than once. For example I hit an uninitialized read error in mbstring, it's been in their bug tracker since 5.x and never fixed. I understand the normal way to deal with memory errors in PHP is to shrug it off because processes are short-lived but if you are security-conscious it is concerning.

Compared to that, working on similar integrations for Python, Java, Node.js, the number of times I've hit such bugs is exactly zero. PHP just seems to have lower quality and worse design overall.

EDIT:

CVE database agrees with my assessment, so many more memory issues in PHP:

PHP: https://www.cvedetails.com/product/128/PHP-PHP.html?vendor_i...

Python: https://www.cvedetails.com/product/18230/Python-Python.html?...

Java: https://www.cvedetails.com/product/19117/Oracle-JRE.html?ven...

Huh, this is one of the first times I've heard critisism about the implementation of PHP, rather than the language itself.

I couldn't find a date on this article, but I don't think this line is accurate anymore:

"Facebook, Wikipedia, Yahoo, Flickr, Tumblr all these sites run in PHP and welcome millions of users every month without flinching."

Facebook dropped PHP for their own language called Hack, which I think is based on PHP but with a lot of the things people complain about changed.

> but with a lot of the things people complain about changed.

and some of those things have changed in base PHP as well too.

I think it might even cross compile in some fashion.

Wordpress. Over a third of the web is Wordpress.

FWIW I found this in the RSS feed for this site:

    <pubDate>Mon, 23 Sep 2019 04:05:19 +0000</pubDate>

I don't mind PHP (like I don't mind lots of things that I don't really have to deal with), but Hack is by far my favorite web language. It has most of what's nice about PHP (specifically, reload and your changes are there, memory is request-scoped, etc.), without most of what's awful (the HSL fixes most of the goofy inconsistencies, real (although still not as expressive as I'd like it to be) static typing, etc.).

I "hate" my experiences in the aughts debugging other peoples PHP code, which put me off. But I primarily use JS now, and I feel like it's just as hated (but maybe more loved?). But I can't imagine how much people would hate JS if node came out in 2001, could you even?

I wonder what people would think of Node if it came out right before the tech bubble burst and the company hosting all the package repositories sank without a trace, taking the packages with it. That would have done some lasting damage to the web development world.

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ is a classic of this genre.

pick a random language, ruby, python, javascript etc etc and you'll find similar rants/complaints. Yet I think right now it's cool to shoot on PHP therefore everyone is more vocal

When someone gives you a long list of reasons why they hate something, why do you conclude they only hate it because it's trendy to hate it?

because this kind of rants are pointless, they are not bringing any value. Every language comes with their own inconsistencies or oddity. Most of those points raised are just added to a laundry list for its own sake, it's not something you come along every single day. You might have a WTF moment once in a while but that's something that happens with every language. I'm still not able to understand why everyone hate PHP and then at the same time love Javascript or Python or Ruby.

Not every language comes with the same amount of inconsistencies and oddities.

As an illustration, compare the amount and severity of WTF moments found in Ruby vs. Javascript in this presentation: https://www.destroyallsoftware.com/talks/wat

Yet I think right now it's cool to shoot on PHP

This is not a recent thing, it has always been cool to mock PHP. It's not entirely unwarranted, but most programming languages have their own warts.

For example, for some reason, creators of dynamic languages think they need to mess with variable declaration, to make it more accessible, or whatever, instead of staying with tried and true lexcially-scoped block-level variables with explicit declaration. As far as I can tell, the result always ends up worse.

I don't know if that has to do with dynamic languages. Elixir reduced the scope of variables so that, for example, you must export it out of if statements, which irritates devs coming from most languages but which I think is a fantastic feature.

> pick a random language, ruby, python, javascript etc etc and you'll find similar rants/complaints

Yes, but that's not the point - the primary trait of "old PHP" (I don't know the "new PHP") is that it has not been designed.

Languages like Ruby, Python, etc. may have been designed, in a better or worse way, but there's a radical difference with a language that hasn't been designed at all.

> I think right now it's cool to shoot on PHP

That article is from 2012. If a "fad" lasts 7 years, is it still a fad?

And she's right. Just the `fopen` example is bad enough. It's characteristic of the whole ecosystem. Python and others do not have issues like that.

It's a footgun waiting to happen as you switch between PHP and other languages.

For a few years now I have been using PHP as a thin-client UI layer on top of C# Web API (dotnet core) projects running on Ubuntu/Docker. In my experience this has worked out very well, and has been easy to separate the areas of responsibility between Software Engineers and Designers.

All of our sophistication and unit tests live inside the C# back-end projects. While the PHP in the UI layer is limited to very simple code like for loops and templating; otherwise they're mostly design projects centered around HTML/CSS/UI/UX. Keeping it so simple makes it rather easy for designers to pick up on and work with.

I started a small website to document this pattern:

http://rapstack.io

I have advocated for its use on most of my projects, but obviously the mere mention of PHP stirs up a lot of knee-jerk reactions.

The article is correct in stating that PHP has moved quite a bit in the last ~10 years; even back when I was using PHP in the 5.1/5.2/5.3 days things were already steadily improving.

But ... that doesn't mean that PHP is a good language, or that people hate in PHP "just because it's cool". There are still many issues that remain. For example the very loose typing checking remains an issue and source of real bugs; e.g. a while ago a SAML library could be bypassed because it forgot to add the flag to in_array() to enable strict comparisons.

Much of the problems in PHP are with the standard library, and this is not easy to fix. Even the mysql deprecation (in favour of mysqli/PDO) took ages. I wrote a thing looking at fopen() in PHP a while ago, and I think it's a good example of the problems that remain in PHP: https://www.arp242.net/php-fopen-is-broken.html

There are still many issues with the standard library like this which are clumsy and just plain design errors, and many of them are too fundamental to work around or fix. Has PHP evolved? Sure, and that's great! But that doesn't mean it's now an especially good language. In general, I'd rather have a poor language with a good standard library than a good language with a poor standard library.

Aside: one weird thing about PHP's stdlib is that it's all written in C; I don't know any other comparable language where all of the standard library is written in C. I think this seriously hamper's the evolution of PHP's stdlib to a more modern experience.

There is no easy fix for any of this btw, because a revamping of the stdlib would likely lead to a "Python 3 scenario", so I don't blame the PHP devs for not fixing it (although I do blame them for introducing new flawed parts to the stdlib, like the whole DateTime fiasco), but that doesn't mean it's not a problem.

I don't like having to hold 'shift' while pressing '4' all the time. Other then that I don't think the language is bad and where you cannot do what you're needing to do. If only I could get rid of the need for $ signs everywhere.

...and "->" to access a method or a variable. Maybe in PHP9

at least you don't have $ # and @ to determine object vs list vs. hash map like perl5. :P

Found the non-Perl programmer (the sigils for scalars, arrays and hashes are $, @ and %).

After I learned PHP 4 right after one of the first books came out, I quickly forgot Perl. So many way to make one liners from symbols. shudders

PHP is my favorite language to write SQL injection vulnerabilities, just like C is my favorite language to write pointer bugs.

(Disclaimer - The last time I used PHP was over a decade ago, and the last time I used C was in college)

You don't have to write pointer bugs in PHP, they are already included for free in the language implementation.

I will say this for PHP: Its interaction with my brain had such a nearly-disastrous impact on my life, that it finally allowed me to finally get the mental health treatment I'd been seeking for a decade, and to realize the fundamental and unfixable weakness of my marriage.

-------------------------------------------------------

If you enjoy eating pad Thai, that is great for you. I do too. But different people are different and the effect of peanuts on some people are quite dramatic yet real.

Choosing not to work with PHP is no more elitist than choosing not to eat gluten or peanuts.

There's an obvious difference between choosing not to use PHP and shitting on an entire language based on a decade's old idea of the language is.

The PHP project experience which cost me a job that I loved, nearly got me kicked out of my home, and prompted multiple evenings of suicidal ideation, and led my wife to be filled with anger at me even 7 months later is from the end of 2018.

I am responsible for how I manage my mental health. Part of exercising that responsibility is my firm choice I will never again work with PHP.

I'm a PHP developer and I really don't like this language. Right now it's paying my bills but I hope my next job won't be related to it. People are saying that PHP has become better and that's very true. But still far behind modern languages like Go, Python, Rust, Elixir. PHP is full of inconsistency, legacy code, and missing features. Core developers are doing great by adding a lot of new stuff and optimizations, but caring too much about backward combability disturbs the language from becoming better IMO.

I'm still not entirely sure why, in plain 2020, PHP seems to be the only language missing a debugger able to run in a shell.

Python, Ruby, Javascript and others have a "debugger;" statement of some sort that, when hit by the execution flow, will pause the code and let you type stuff in your shell, letting you inspect the code, step forward, etc...

Why does PHP need me to configure an entire IDE or my browser? (I'm looking at you, xdebug). Why can't it have a cli-debugger?

> Most developers who hate PHP hate it out of elitism or ignorance.

I don't think I'm an elitist. I inherited a system that was written by a pretty bright guy without a lot of programming experience: thousand-line files mixing logic and presentation, that sort of thing. It was a bear to maintain, it was a bear and a half to secure. It gave me a distaste for PHP, yes.

I don't hate PHP, I'd just rather use something else.

> PHP is an old man who doesn’t want to sell his land. An old man who continues to dance insolently.

But in this case he is terribly ill and not actually dancing but having a condition called Chorea that is often mistaken for dance like movements

https://en.wikipedia.org/wiki/Chorea

> Developers hate PHP because you are more likely to get errors with a language that allows so much freedom.

Ruby gives you much more freedom than PHP. You can reopen classes, you can use any kind of object as a key in an associative array, you can write code that will execute when the class (not the instance) is being created. And yet I find it much easier to write stable code in Ruby.

> Developers hate PHP because it is the opposite of hype driven development

Does C# gets so much hate? Or Python? I don't think either of them is an example of hype driven development, and yet they are rather respected languages that don't get so much hate.

> Developers hate PHP because they believe the language has been stagnating for 20 years.

Again, I don't think that's it. I've been using PHP7 for the last few months and yes, it is different from PHP4. You have optional static typing, you have better tools, a lot has changed. Yet deep in its core the language is still badly designed. I constantly find some weird behaviours that just don't exist in other languages.

Example:

  $array = [1,2,3,4]
  array_filter($array, function($x) { return $x %2 === 0; });

In every other language I've used, such function would return [2,4], but not in PHP.

  array_merge(
    [ "a" => "w", "1" => "x" ],
    [ "a" => "y", "1" => "z" ]
  )

In every other language I know, it would return [ "a" => "y", "1" => "z" ], but PHP returns [ "a" => "y", 0 => "x", 1 => "z" ]

I know, these are just random examples and every language has its quirks. The problem is that in PHP there are so many quirks I keep checking how each function works, because after half a year I still can't remember them (and I don't remember whether array is a first or a second argument, because it depends on a function).

I wouldn't say that I hate PHP. It's another tool that I know and am able to use. I just think in 2020 in most cases when you start writing a new web application, there are plenty of better options. So maybe that's where the hate comes from? That there are simply many more consistent languages that just remain less popular than PHP?

php > $array = [1,2,3,4]; php > var_dump(array_filter($array, function($x) { return $x %2 === 0; })); php shell code:1: array(2) { [1] => int(2) [3] => int(4) }

what's the problem with array_filter then? That keys are not reindexed?

Yeah, an array essentially becomes an associative array. For example in another language I could do something like:

  if (!empty($filteredArray)) { print($filteredArray[0] }

But in PHP I need to remember that after every array_filter, after every unset etc. I need to reindex the array, because [0] element might not be there

It was an associative array all along, PHP just hides that from you. The Array is such a quirky data structure, it takes int or string keys, but numeric string keys ("1", etc.) are silently converted to int. It's never a real array, the implementation under the hood is a hash table.

Did anyone here start learning PHP in 2020? How were you introduced to PHP? Are there any good resources to start with?

When I was introduced to PHP everything was still in a single file, PHP, HTML, JS, CSS.

PHP being awful annoys me so much more than javascript being awful.

At least for the latter the use became mostly unintentional. For PHP, the problem is that it came about at just the right time to be picked up by WordPress and Facebook, hence encrusting itself in most of the web we see.

I dislike WordPress the same way I came to dislike Visual Studio or any other monstrosity. It's a slow, massive, lumbering mess but it's also by the most mature tool for the job it does.

There's no reason to pick up PHP for a new project. Except, I guess if you're just doing simple CRUD and PHP is what you know.

Languages don't matter that much for simple CRUD apps and PHP is a sub par, annoying, inconsistent language that will get the job done.

PHP via HHVM + Laravel is a still top choice for new projects imo.

Why with HHVM? PHP7 is pretty fast, I believe the fasted non-compiled language there is.

good to know, i hadn't fully dug in yet.

I'm currently on a project building A CQRS system in PHP (not the first time) . I have no idea what you are basing this on.

he's basing it on PHP 10-20 years ago, just like the article explains. :P

wordpress would be a slow, massive, lumbering mess in any language. It happens to be in PHP but you would get same result if it was built in python or javascript. Any dynamic language in the wrong hands can lead to that same result, at least PHP managed to introduce stricter typing and so on while other languages have arrived way later (Javascript must use TypeScript and Python is going through a slow and painful migration out of Python2)

> For PHP, the problem is that it came about at just the right time to be picked up by WordPress and Facebook, hence encrusting itself in most of the web we see.

That's backwards in my opinion. PHP was successful among non-CS-people, and those people started building things they were interested in. That gave PHP the initial success (especially on the web, were plenty of people didn't have a CS background unlike in enterprise software), which lead to people like Larry Sanger and Jimbo Wales using PHP to build their first version of Wikipedia. And it also lead to PHP being the go to thing for websites, pushing aside Perl, which meant that when Zuckerberg wanted to build a site for fun to rate coeds, PHP was a natural choice. Quick to build, easy to deploy, not a lot to worry about.

I'd be surprised if somebody back then planned to invest a huge sum of money and create some giant system and chose PHP. But PHP just being there, highly available, and people using it for all kinds of random stuff and then some of those things taking off and PHP just remaining at their core because of inertia, that's not surprising imho.

The first version of Wikipedia used usemod, which is Perl.

The "phase II" version in PHP was written by Magnus Manske (who is indeed a non-CS-person).

Oh, I was not aware of that, thank you.

What was the point in this comment? You basically just complained about a bunch of random stuff. I can assure you that you're way more bent up about this than any PHP dev would be from reading this comment.

ugh. You lost me when I saw the first of several huge gifs and memes inserted throughout the article.

I haven't used PHP since 2012 so I don't know if any of the stuff that made me hate it still applies. A lot has probably changed since, but I don't know to what extent.

Surprisingly, the technical inconsistencies isn't what I hated most about it. It's rather the fact that questionable practice was rampant and largely left unchecked in its many communities. The only way to realize this is to join another community where peer review is severe enough and bullshit detection high enough that mediocrity is rarely given the opportunity to infect your practice for long and fester. A proper community is supposed to nurture you into becoming a better programmer, so that you can take those lessons and carry them with you wherever you decide to go next. By contrast, my experience with PHP over the 6 years or so that I used it was that you learn 3 things today and you'll have to unlearn 2 tomorrow. Eventually I got fed up of the cyclical learning pattern and I moved on.

Some years after my move away from it, I decided to take a look back at some of the code that I had written with PHP. I was freshly appraising the sum of my past experience. I remember thinking that the language seemed to have a crisis of identity. It was dynamically and weakly typed, but with serious Java envy and so some of the less desirable aspects of Java were basically just cargoculted in, but in a shitty incomplete way. Private, protected, public class members, what a joke. If you're a PHP programmer, did you ever ask yourself why would Python or Ruby programmers somehow be able to get by without this shit and not you? Do you know that because of the way its interpreter works there are some technical benefits for Java to have these besides the fallacious architectural "advantages" of hiding access from the programmer? Does the same thing apply to PHP? Interfaces and inheritance, without the possibility to overload methods, which can cause a lot of grief when a zealous and inexperienced library designer hasn't properly thought things through (which happened more than I'd like to remember in PHP projects). That was just at the language level, but many of the big frameworks followed suit with the Java obsession, by implementing a slew of circuitous patterns aimed at convincing programmers that they were now coding "Enterprise Style". Front Controller, Action Controller, Dispatcher, and a whole other lot straight out of pattern catalogs. When you think about it, most of those efforts were fallacious in PHP. If the problems that you were trying to solve were beyond the constraints of what PHP is typically good for, namely cms-type admin web apps, then you were probably better off with another language. On the other hand, if they applied, why bother with all the enterprisey bullcrap? But, but, but Facebook... Ah, shut up! Even Facebook had to invent a whole other language to fix that mistake. The other projects that didn't buy into this sort of architectural zeal went the other extreme, with their own experimentations and idiosyncrasies. Bastardizations of concepts that someone had seen somewhere else, but only half-understood, was common. Lots of Rails envy and no shortage of fame-driven wannabes that had failed to make a name for themselves in other communities, but somehow always found a way to shine in PHP. Ensued just more bullshit.

Anyways, that was a long time ago. I hope things have changed. I'm not sure I'd be back if they did, in hindsight what PHP has for it is one of the easiest "hello world" tutorials, but you end up paying for years the half-hour you saved to see these two words on a web page. And for what it's worth there are worse languages, but there are better ones too.

There is no web framework out there which comes with such elegant concepts, syntax and feature-richness like Laravel. I have seen them all - Laravel is incredibly good, especially for small - mid sized projects! And this statement comes from a python guy.

Why do you prefer it over say, Flask or Django?

Laravel performs way better than Django, I also prefer the migrations/model styles that resemble Rails a bit more.

Django might be better w/ 3.3 or whenever they fully integrate async into the view/db layer, but w/ laravel I can plug in swoole and go from 110 reqs/sec to 4600+ on my dev pc - w/ 12 threads and 200 connections hitting a post api logged in, updating the database and the caching layer, and queuing notifications.

Just ran some big benchmarks on laravel w/ php-fpm vs swoole last night...as an aside. I also don't like some of the ways django handles auth. If I were to use python, I'd definitely go w/ FastAPI, it seems much more joyful a framework.

I'd also love to do something like go for sessions/auth/jwt and hasura, postgraphile, or postgrest or some sort of api from postgres, and then most of the logic would simply be postgres functions/triggers/etc...there's also some nice 'built-ins/ecosystems stuff that even rails lacks'.

Auth is built in, vs devise (being almost a requirement). Message queues, notifications, .env, events/listeners, are also all built-ins. Eloquent is nice, though repositories using straight sql or the DB class are probably more performant, but you lose a lot of the magic that makes laravel nice, so there's trade offs. Also all the many drivers for caching/queues/etc and telescope is a very beautiful way to debug and so is ignite for error pages.

Horizon is nice to manage queues/etc. I keep trying to move to another framework just for the sake of 'something new' and boredom but after 8 years on laravel, I still keep coming back. Wordpress is a totally different story, I charge 35% markup on my normal rates just to touch wordpress because it sucks so bad and hurts my brain to work w/ it. Also, I don't really need to worry about how to setup vue or react, laravel-mix pretty much handles all the webpack stuff w/ a few exceptions if I'm using Tailwinds or creating aliases for paths, etc...

I'm convinced that Laravel and PHP are (literally!) best-in-class for the user-facing web layer of any HTTP based application.

The tooling, resources, first party libraries, and general ecosystem is VERY evolved, and the framework can makes you VERY productive.

I've used Laravel, not a fan. I believe that it's too wrapped up in magic, it actually gets in the way. Also bad naming choices for patterns and Active Record style DB stuff just leave some more bad tastes in my mouth.

I created an account just to reply and say I couldnt agree anymore with your statement. I have used multiple frameworks and Laravel towers above them all in terms of feature-richness.

I have spent the few days trying to get into Phoenix and as interesting as it is, it would require me to re-invent the wheel for a lot of things that laravel just offers you out of the box. a quick example is subdomain based routing or even its robust notification based system.

For all the hate laravel gets , it level of productivity is unmatched once you know yor way around it.

Reply on news.ycombinator.com