[mrrsm]

PHP, since version 7.0, has been a much improved language since when many people started hating on it. They have been consistently moving the spec forward and making improvements. It's not perfect, but no language really is after all. It is really nice just seeing issues that have been around for a long time being addressed and fixed.

[rglullis]

I have to confess that I have a lot of prejudice against PHP after having to work with it at the time of PHP3 and 4. It seemed like even worse than Perl in the sense of how many things were just bolted on it as a way that the developers could claim "yeah, you can do that with PHP". After having a blog running wordpress hacked twice by mere virtue of being online, I dismissed it for good.

I keep hearing about how the language has improved, but to me it feels like even if the language gets rid of all its heaps of crap, it still is in a evolutionary dead-end. Is there anything that PHP is developing or adopting that can not be had at other established languages?

(Edit: I never had something downvoted so fast before. This is not concern trolling. I seriously would like to know if it makes sense for a non-PHP developer to look into it)

[CiPHPerCoder]

> Is there anything that PHP is developing or adopting that can not be had at other established languages?

Modern cryptography is baked in since 7.2.

https://libsodium.gitbook.io/doc/bindings_for_other_language...

Most of the people who shit on PHP have a lot of love for other languages. A survey of the cryptography features the "favored" languages offer will almost certainly fall into two camps:

1. "We wrap OpenSSL"

2. "Go compile it yourself" (i.e. there is nothing baked in)

There's a lot of badness with OpenSSL's API design, especially with asymmetric cryptography. For a fun exercise in these languages, try encrypting with RSA with OAEP padding, but without using SHA1 as your hash function.

For completeness, PHP is one of the languages that wraps OpenSSL too! But it also wraps libsodium, and the community has been moving towards libsodium (unless they need something from OpenSSL for the sake of backwards compatibility) since early in the 7.x series.

If you're going to provide cryptography features in your language, but you aren't shipping modern cryptography in your standard library, you're underperforming what PHP has offered for years at this point. The easiest way to meet the standard that PHP 7.2+ establishes is to add libsodium to your language's standard library.

(There are salient arguments for "why even provide a cryptography feature as part of the language at all?" but most of the languages that see real world deployment are already doing that.)

[smt88]

> after having to work with it at the time of PHP3 and 4

PHP 5 was released 16 years ago and was a massive evolution of the language. The same is true for PHP 5.2, 5.3, and 7. It's safe to say that your conclusions about the language are no longer accurate.

> Is there anything that PHP is developing or adopting that can not be had at other established languages?

No. I can't think of any reason to start a new project with PHP today. All of its best features are things that have been available in other languages for years. It's also not particularly popular outside of WordPress.

[wyck]

WordPress accounts for approximately 60% of all websites, PHP accounts for approximately 79% (knows server side sites). So I would say it is particularity popular.

[NationalPark]

I'd like to know more about that 79% number. I would guess it's actually the case that PHP backends identify themselves as PHP far more than backends in other language x identify themselves.

[pests]

That doesn't make sense. If you test 100 sites and 79 come back as PHP you can't just claim that the 21 responses that came back blank somehow is a bigger number than 79.

[KerryJones]

Laravel is decently popular, has the most *s on github for a backend framework I believe (or it did at one point in time) and in a number of Fortune 100 companies.

May not be as popular as React/Flask backends, but it ain't nothing.

[tambourine_man]

Wikipedia? Facebook?

[ragnese]

They said today. Those sites were not started today. Furthermore, Facebook literally invented a new language because PHP wasn't good enough. PHP has since adopted some of the features of that language.

[kamel3d]

I don't know how can you blame the hacking of your website on the language rather than your admin skills, there infinite number of websites built in PHP and never got hacked!

[rglullis]

I wasn't hosting the blog. It was on webfaction.

> infinite number of websites built in PHP and never got hacked!

If I look at the logs of my webservers and scan for bots trying to exploit some vulnerability, I would guess that 80%+ of the URLs would indicate a PHP-based webapp. So, yeah, there are many that never got hacked but there are certainly a good amount of PHP apps that have some vulnerability. Should we blame all the developers who were "doing it wrong" or should we at least make sure that the language is not facilitating such shots-in-their-feet?

[jjeaff]

Well, php is thought to power something like 80-90% of websites. So you are seeing either the same or disproportionately fewer php sites than you should if php were in fact less secure.

But php has been around on the web for a long time as well, so there are a lot of unpatched softwares out there like WordPress.

Probably near 99% of those compromised servers run on Linux, so by your logic, Linux is much more secure than windows servers, right?

[rglullis]

> So you are seeing either the same or disproportionately fewer php sites than you should if php were in fact less secure.

You'd have to assume that there is an uniform distribution of vulnerabilities and exploits through the whole set of languages used for web development for that to hold. You are begging the question.

> 99% of those compromised servers run on Linux

If the exploits manage to give the attacker root access to the OS, then yes it would be the problem of the OS. But the attack is to get access to the application. So the issue is at the application, not at the OS. You can argue that this is not the fault of the language, though. However given that a whole lot of the PHP defenders here are using "it is the easiest one to deploy" argument, one has to wonder if a platform that makes it so easy to deploy apps should also be held up for the issue of insecure apps based on it.

[edoceo]

You see lots of PHP because there is lots of PHP. The hits are because of wide adoption not language vulnerability.

[throwaway8941]

Considering the number of vulnerabilities frequently found in Wordpress and its popular plugins, rglullis' admin skills would not be the first thing I'd personally put the blame onto.

[skrebbel]

By the way you phrase that question, you're dismissing that single key feature that PHP _already has_ that cannot be had at other established languages.

I know of no other language that lets you deploy a web app by dragging some files from the left to the right in FileZilla. No setup, No vendor lock in, no nothing. It just works.

Cross-cloud serverless frameworks that wrap AWS lambda + competitors get you somewhat close in other languages, but you still have a lot more setup to go through, and lot fewer hosting providers to choose from.

PHP's deployment and execution models really set it apart.

[ragnese]

You cannot deploy a PHP app by just plopping a file on an unconfigured server.

Deployment is not that simple.

Or, if it is, then you have to allow me the same grace of just being able to plop my Go or Rust binary on that server and have it magically work. It might even work BETTER because I don't need to check if my php.ini matches my dev machine.

[skrebbel]

There are tens of thousands of hosting providers around the world that offer exactly this service.

[rglullis]

Right, but isn't precisely this "drag from left to right and get a website running" that leads to an endless stream of sites that get hacked because the developer was careless/ignorant enough to leave admin.php with executable permissions?

[jasonlotito]

No.

[muglug]

> Is there anything that PHP is developing or adopting that can not be had at other established languages?

No, not really, but it's still very good for casual web development, which makes up the lion's share of all backend code being written today.

Languages don't need to evolve a ton to be popular – just look at Python, which is doing very well despite not having had a ton of radical changes.

[rglullis]

It's not "just" the language. It's also a matter of what the improvements bring in for possibilities of new developers and mindshare.

Python as a language hasn't changed much, but it made huge strides into the scientific community and got a lot of marketshare from ecosystems like R and Matlab. It's becoming king in the ML/AI side. Go is growing in the backend systems/devops stuff that used to be the realm of Python. Rust is getting more and more adoption as a systems language and focus on safety. Even Java seems to be adopting things that make it less bureaucratic while being general enough for the enterprise.

I am not saying that PHP has to go away or anything. It's just that I wished that new releases could have more interesting things to say besides "it's not as crappy as it used to be".

[muglug]

> It's just that I wished that new releases could have more interesting things to say besides "it's not as crappy as it used to be".

I don't think there are many people in PHP's orbit who want it to be a better Python, or a better Perl/Ruby/JavaScript.

PHP was written to be a good language for average web development, and I think that's where it will always shine. I'm perfectly happy with a gradual process of making it less crappy.

Having said that, I'd love some of Hack's features (e.g. reified generics, proper list/dict primitives) to make it into PHP.

[ragnese]

> Is there anything that PHP is developing or adopting that can not be had at other established languages?

IMO, no. The language is still near the bottom for both dynamic and "static" typed languages. HOWEVER, if you're doing web backend stuff, Laravel and Symfony are both really solid frameworks.

The direction PHP Is moving in right now is to emulate Java 7, but without generics or concurrency. It's definitely a dead-end unless they come up with something pretty novel and change direction (again).

[core-questions]

> IMO, no. The language is still near the bottom for both dynamic and "static" typed languages.

Why do you say that? It's faster than Python and Ruby for most cases, still extremely simple to deploy, the package manager (Composer) is very predictable and easy to deal with compared to Pip or Rubygems, the documentation is good, etc.

It has clean lambda functions that you can pass around easily and has for more than a decade. Type hinting has been in place for a long time, too, as have enough OOP / reflection constructs to do just about anything you'd reasonably want to do in a language aimed primarily for web development.

The only downside of PHP that I can still point to is that it's sometimes hard to remember the function parameter order for some of the common string and array functions. Far from a dealbreaker, that.

[tuco86]

I don't agree with the faster and extremely simple to deploy points, at all. Both objections have to do with php-fpm.

it spawns a new php interpreter for every request, which means for example that symfony framework setup (routes, controllers, service dependencies...) have to run before every request. Sure it does that faster than python, but python only needs to do this once.

deployment is my personal nightmare. try to set the max children or whatever so concurrency is ok but memory does not run out. I mean facebook did it so it has to be possible but damn, that was hard to get `right`. Setting up logging is a mess. There is the application, the admin and the fpm error log, I gave up trying to have every log event logged exactly once. Segfaults are a common occurrence, still. I heard it mentioned just before leaving for vacation.

[core-questions]

> Both objections have to do with php-fpm.

To be fair the last time I seriously worked with PHP was back when mod_php was still cool. I was able to serve thousands of users on a dual-core Xeon box ~15 years ago - I can only imagine the performance is better in many ways now.

[ragnese]

As a statically typed language, I feel like it doesn't even take much to explain why it's actually the worst, except for C. But at least C is necessary in some domains.

The type system is weaker than Java, which is a low bar.

It has no generics, which means no real containers, no generic functions without dropping all typing, no type-hinted arrays.

Arrays are also not objects, so they don't conform to any interfaces, which is related to the "no real containers" issue.

It took until version 7.4 to actually have covariance and contravariance! Before that it didn't even implement inheritance correctly!

You can't typehint for function-as-param beyond just writing `callable`. So if you want to use those nice lambdas and still be statically typed, you're SOL.

It's definitely fast for a scripting language! So, that's fair. But it's still way slower than many other good backend languages: Java and other JVM languages: Kotlin, Scala, maybe Clojure?, Go, Rust if you're feeling frisky.

I've never used Ruby and I'm generally biased against dynamically typed languages, so that's the background for my assessment. The dynamic languages I've used in anger are Python, JavaScript, Elixir, and Clojure.

The package manager is better than the disaster that Python was the last time I used it. Agreed. It's also better than NPM, but not enough to matter most of the time. It's not better than Hex or Lein. Also, managing packages is a) not the language, which is what I criticized, and b) not where you spend most, or even a large part, of your dev time.

Looking at PHP as a dynamic language, I'd say that the built-in array is still a huge disappointment and the API sucks compared to either of Python's dict or list. It's much cleaner in JavaScript, Clojure, Elixir, and Python to define and operate on new, untyped, objects.

Also, for a dynamic language, I'd at least want SOME benefit to it being dynamic. For JS, Clojure, Elixir, and Python, the REPLs are great. The PHP REPL is... primitive.

None of the things you mentioned in PHP are actually better than any other language I've used except for the package manager. Its lambdas are not even better than any of the languages I've listed. In 2020, decent lambda syntax is table-stakes.

[core-questions]

> It has no generics, which means no real containers, no generic functions without dropping all typing, no type-hinted arrays.

These things are a little advanced for the likes of me. Any chance you'd be so kind as to give me an example of something I can't easily do because of not having this?

> It's definitely fast for a scripting language! So, that's fair. But it's still way slower than many other good backend languages

But those languages require compilation and deploy cycles that are way longer than just getting files on disk, so the total cycle time of development may end up being longer in many cases. It's a tradeoff. PHP probably shouldn't be used for performance-critical things, sure, but then neither should any other dynamic language.

[ragnese]

> These things are a little advanced for the likes of me. Any chance you'd be so kind as to give me an example of something I can't easily do because of not having this?

Well, you can do whatever you want in a dynamically typed language. I was discussing the shortcomings if you choose to use PHP's type system.

If I'm using my static types and see `function foo(): Bar` I take comfort that I will receive a `Bar`. If I see `function foo(): array` I have absolutely no idea what that array is. Is it a list of `Bar`? Is it a dictionary of some kind? Is it a heterogeneous list of bools, ints, and Maseratis?

Also, real containers are useful. A true array is a contiguous slab of memory. PHP's array is not. The performance characteristics will be very different. If you had a `Set<T>` type, you could guarantee that there are no duplicates in the set. That is sometimes very useful. No such thing in PHP. PHP arrays can't even be used as a real `Map<String, T>` because if you do `$arr["1"] = new T()`, it wont actually have "1" as a key! It'll transform the "1" into 1 and store it in the 1th slot, like an array!!! Totally flipping useless.

> But those languages require compilation and deploy cycles that are way longer than just getting files on disk, so the total cycle time of development may end up being longer in many cases.

Are you suggesting that you write PHP code and then plop in on a production server without running tests? Because running your tests is comparable to the compile cycle of Java et al. Except in those cases I don't have to write entire classes of tests, whereas you should be writing type-checking-style tests on your PHP code. You just have to be the compiler to make sure your inputs are validated correctly.

> PHP probably shouldn't be used for performance-critical things, sure, but then neither should any other dynamic language.

Then what was the point in comparing PHP's speed to Python? They're both slow and shouldn't be used for performance-critical things. That's fine, but then find me a selling point.

[Nullabillity]

> still extremely simple to deploy

Hardly. PHP-FPM is a confusing mess to set up, and you're still stuck working around the massive mistake of binding routing to the file system.

And I hope you don't try to just rsync up your changes afterwards without some form of blue/green deployments.

> the documentation is good

There is.. a lot of it, for better or worse. Let's compare the functions for concatenating lists between PHP[0] and Scala[1]. The PHP version is way longer and contains several examples.. that are only needed in the first place because the PHP's array type is so messy and tries to fill so many different uses. Meanwhile, Scala's gets to the point, describes how to use it, and uses the rest of the screen estate to help me navigate to anything else that might be relevant.

> It has clean lambda functions that you can pass around easily and has for more than a decade.

Looks like they did finally clean up their baffling closure binding syntax in 7.4... unless you want to bind anything by reference.

That said, it is pretty hilarious to me that they decided to make strings and arrays of strings callable rather than add some kind of first-class function reference syntax. Surely that won't have any confusing interactions with namespaces...

> Type hinting has been in place for a long time

Not of much use without generics. `array` isn't a particularly useful type. There does seem to exist an RFC[2], but it looks dead in the water (no voting table, and the stated vote goal was years ago).

> The only downside of PHP that I can still point to is that it's sometimes hard to remember the function parameter order for some of the common string and array functions.

It's not really PHP's fault itself, but Laravel is a miserable mess of implicit magic. The fact that people often seem to hold it up as the gold standard of PHP doesn't exactly inspire confidence in the community.

[0]: https://www.php.net/manual/en/function.array-merge [1]: https://www.scala-lang.org/api/current/scala/collection/Seq....):Seq[B] [2]: https://wiki.php.net/rfc/generics

[jbboehr]

> you're still stuck working around the massive mistake of binding routing to the file system

fastcgi_param SCRIPT_FILENAME /var/www/index.php;

[core-questions]

> Not of much use without generics. `array` isn't a particularly useful type.

No, but you can do function foo(SomeClass $x) {...} - doesn't that fulfill the use case for most people? Objects are basically fat types, in a sense, no? And since the OOP hierarchy is respected, I can use interfaces or abstract classes here and get basically what I want...?

[keanebean86]

My favorite thing about PHP is the documentation! The comments often have exactly the example I need to do whatever simple thing I'm trying to accomplish.

[bogdanu]

Parameter order was somewhat resolved with the introduction of named parameters in the upcoming php 8 release from this year.

[core-questions]

True, but I doubt I want to use that on a simple string function. I'd actually much prefer to see the introduction of methods on strings ala Ruby and most other natively-OOP languages rather than calling the C-style functions with the strings as a parameter, but hey, it is what it is.

[bogdanu]

Not gonna happen, but you can always use Symfony's String component that has API like that.

Sure, it's not built-in, but I think this is the best solution for now given the size of PHP's language team.

[dktp]

> Is there anything that PHP is developing or adopting that can not be had at other established languages?

I think for the vast majority of projects, this is not a question you'll be asking yourself when picking the language.

I think PHP is one of the best languages to pick when you want a quick MVP for an online service (one that doesn't require specific things PHP is not good at). The community is one of the largest, there are more developers than nearly any other backend language and Laravel is probably the most complete all-in-one backend framework out there.

So the question is often, is PHP good enough to develop a maintainable app with decent performance, where developers won't hate every minute spent on it. And the answer is pretty much yes with PHP 7+

[open-source-ux]

"Is there anything that PHP is developing or adopting that can not be had at other established languages?"

One thing that PHP does better than any other language for web development is ease of deployment. It isn't really anything inherent in the language that makes it easier to deploy, it's simply that hundreds, probably thousands of web hosts have made deployment easy for PHP. Also, the PHP community has documented deployment and installation scenarios thoroughly.

Deployment might sound like a small piece in the overall picture of building a web app but it is actually hugely important. If you want your users to self-install your web app, or to give them the widest possibly choice of deployment hosts, then PHP beats every other language by a mile.

I always mention this quote from blogger and programmer Jeff Attwood on this topic of depolyment:

"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option." [1]

Guess when he wrote it? 2012.

Sure, we've got VPS and even more hosting options, but in 2020 what other languages can match or even surpass PHP's ease of deployment? Can you give instructions to your relatively non-tech users and tell them how to successful deploy your web app with the same ease as PHP?

[1] https://blog.codinghorror.com/the-php-singularity/

[jasonlotito]

> Is there anything that PHP is developing or adopting that can not be had at other established languages?

I feel like I can ask that question about most established languages and get the same answer back. It still has the easiest deployment and development flow of any language I've ever used. I don't know of a single language that does that right now, and makes going from 0 to 100% much easier, which for smaller pet projects, it's so much less hassle. Upload file, it's running on the web. That's it.

As for all the features it has that other languages have, PHP tends to merge them together. While this means the language is larger than most, it also means I can do things in ways I want to and try new features out.

This doesn't mean I'm not using JS or Go or Java or other languages. But if I'm building a web API, PHP is the one that gets out of my way and lets me build it quickly and easily.

[alganet]

> Is there anything that PHP is developing or adopting that can not be had at other established languages?

Good documentation and reasonable backwards compatibility.

[rglullis]

You can have both at other languages and platforms.

[alganet]

Can you name a few that already do it?

[RussianCow]

> Is there anything that PHP is developing or adopting that can not be had at other established languages?

Probably not, but that's the wrong question. The real question is: If you already know PHP, is there enough incentive/benefit to switching languages? Based on the experience of PHP devs I know (I personally haven't used it in years), the answer is "no" for many (most?) web dev cases.

[Lazare]

> Is there anything that PHP is developing or adopting that can not be had at other established languages?

I would say no, but of course, the same is true of most other established languages. What's interesting about PHP is that it's shifting from being a dumpster fire that you would never pick over a real language like Python/Ruby/node/Java/whatever, to one that's honestly broadly comparable for many tasks.

Is it innovating or doing anything really unique? Well, no, but you don't tend to find much innovation or unique features in any of those languages (these days, anyhow). At best they copy them (eventually) from the innovative languages. :)

> I seriously would like to know if it makes sense for a non-PHP developer to look into it

No more or less so than any other big, mainstream, relatively popular language. Learn it because you need it for a job, or because you'd like to see how another language ecosystem solves common problems. Don't learn it thinking you're going to see anything especially new.

[stanmancan]

As a gross oversimplification, I would say that the vast majority of languages share the same core functionality, then there's a little sliver that sets them apart from others and makes them unique. I would probably say that what sets PHP apart is it's easy. It's easy to install, use, develop with it, deploy, find hosts that support it, and get help from the community.

It's a decent language and with frameworks like Laravel you can quickly build reliable CRUD apps, which is the vast majority of websites and development.

[beberlei]

PHP has sort of done serverless in 2000, so evolutionary dead end is a a bit harsh :)

[rglullis]

Do you mean cgi-bin? If that is the case, Perl and C had it beat. ;)