Hacker News Reader

Comment by hu3 | Hacker News Reader

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

View on HN

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.

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.

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

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

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

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 :)

Reply on news.ycombinator.com