3 ms·

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

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.

hu3 6y ago
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.
- kbenson 6y ago
  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. :)
aries1980 6y ago
> 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()...
- kbenson 6y ago
  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).
  - aries1980 6y ago

hu3 6y ago

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.

kbenson 6y ago
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. :)

aries1980 6y ago

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

kbenson 6y ago
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).
- aries1980 6y ago