I don't think PHP's main problem is speed. It's generally used for websites, and a few milliseconds aren't going to make a difference when pages are so bloated by JavaScript libraries to often be 5-10MB.
PHP's problem IMHO is that I wouldn't be able to use it if it wasn't for autocomplete: inconsistent function names, inconsistent parameter order.
The ecosystem is fine, there's Composer, PSR, Laravel. The problem is PHP's legacy.
I wish someone created a PHP class one could use to namespace sane function names and parameter order:
So the main issue with php is a few functions have inconsistent parameter order? Ignore the massive speed improvements, composer package manager system or huge community. Good companies use php. I haven't met someone at facebook that can't code it. (please spare me the HHVM comment or how your intern friend does haskell in the basement).
Have you read about python 2 vs 3? Have you actually seen real programming language issues? Or tried to scale rails? Or worked on deploying java with 30 other people? Tracked a memory leak in c++? Been thrown into callback hell of node? Have you tried to get stackoverflow answers while developing in MEAN.
IMHO people are just justifying their own stack (while secretly suffering with python - a 26 year old programming language) [1][2]. In reality they know php can do anything web / probably in less lines, portable, with easy to find information, with a strong community, in less time, faster. I will let everyone get back to figuring out what the difference between urllib and urllib2 is in python.
Well, I specified "IMHO". That's the main issue that I have with PHP.
I have no idea what they do at Facebook, and I don't have to work on the biggest community in the world that often.
The problems I encounter in term of performance for websites/apps are along the lines of pages being super-slow because of the 100 JavaScript frameworks we like to use nowadays for the smallest of projects, my clients uploading 10MB images that get resized via HTML and still load at full-resolution, etc.
As for coding yes—one issue I have is that not using PHP exclusively I get confused by the fact that the opposite of html_entity_decode is htmlentities and not html_entity_encode, and that slows me down for no apparent reason except the fact that 20 years ago one guy added htmlentities and another guy html_entity_decode, and no one thought about aliasing or deprecating one of the two to fix the unintuitive naming.
"As for coding yes—one issue I have is that not using PHP exclusively I get confused by the fact that the opposite of html_entity_decode is htmlentities and not html_entity_encode"
Ah yes. You will probably have to hit 'tab' on your IDE with php - to type "html_entity_encode". But if this is too hard - Here you go,
Try it out in python (careful of the 2/3 quirks!):
If you start typing `html` trying to get to `html_entity_encode` you'll notice a dropdown which will show you the right method to use. Unless you use notepad.exe or something.
Unless you only write a few lines of PHP every couple of days then you quickly learn what is what, and order of the function signature... I left for 2 years and came back and took me 3 days to get back to the state I was before.
Do you have a public example that illustrates how PHP/Hack code in Facebook looks like?
My problem with PHP is that most of modern frameworks seem to take a lot from Java, and people have started to use type hinting whenever they can, so the code looks like (uglier) Java, but without advantages of performance (being made worse by having to setup everything on every request) or compile time type safety.
> being made worse by having to setup everything on every request
That does have advantages though, I have yet to see a popular PHP application break down due to memory leaks, compared to almost all Java code I've seen eventually ending up in memory bloat...
1) php doesn't have to setup everything on every request - opcode caches, process pooling et al exist
2) the benefit of php over java is that php is going to run everywhere with no effort, and running that same java based website/service is going to start with some doc on installing tomcat or similar, which will devolve into chaos as you start working with ssl certs or shared servers
Flat disagree. The php framework is going to run on every shared host in the world, and sprint boot isn't. I'm not saying PHP is better, I write java all day every day, but if I had to build a website for a random friend or family member, I'm writing it in PHP, because I know their hosting will run it.
I usually just create a VM from a DO template and that's it, no NGINX stuff (although it's very easy, NGINX has good documentation and sane and working default configuration).
>PS. Also, wtf does javascript librarys have to do with php.
The reference is likely pointing to the idea that individual url response times or throughput isn't the whole story. A php site that can do 1000 transactions per second may outrun a nodejs site that can do 3x that, if the individual pages drive fewer xhr requests per page. Or the client side js may be so bloated that the page doesn't render any faster if you make the back end faster. I've certainly seen SPAs that stall parsing/executing js for longer than the remote requests take.
Sometimes client side matters more than server side.
I work on a modern PHP 7.1 codebase, and I personally disagree:
> PHP's problem IMHO is that I wouldn't be able to use it if it wasn't for autocomplete: inconsistent function names, inconsistent parameter order.
I know the functions you're talking about, and they're definitely a wart, but approximately 0% of my day is spent actually calling them directly. I spent a lot of time working with eg, collection classes which extend a base collection class which, sure, calls one of the interchangable array_* functions with their endlessly inconsistent parameter order, but I'm not calling them. Similarly, a lot of code I write every single day relies on encoding and decoding HTML entities, and yes, the fact that it's html_entity_decode and htmlentities is certainly embarrassing, but again, it's all handled by a library.
It's an issue, but I'm not sure I'd find room for it on a top 10 list of issues with PHP. How about, say, the lack of generics? Now that's a flaw that actually impacts people using PHP professionally, whereas the htmlentities/html_entity_decode thing, in my experience, doesn't.
Well, the speed improvements unlock new kinds of things you can do. Old-style PHP code had to off-load any significant work to extensions, which made PHP a glue layer between the browser and the thing that did the real work. Now it's fast enough you can actually write all the code that does the real work in PHP.
I spent 10 years writing PHP, and lately I'm writing Java, Scala and Node code instead. In each case it was due to needing specific libraries that PHP didn't have, but it did give me some insight into what PHP is missing to no longer be the glue layer but a real platform for "serious code":
1. No more ugly mix of procedural and OO code. I want all of PHP's stdlib to become object-oriented, including the primitive types. Also, I need a real type-hinted collections API, not just all-purpose arrays with global functions as primary API. Yes, it's just syntax. Yes, it does matter, a lot, even if you use phpstorm and auto-complete all the things.
2. Generics. Without generics it's impossible to do a properly type-hinted collections API, or a type-hinted FP library. Don't get me wrong, I don't want to type-hint all the things, but I do want to have type-hinted API's to build my own code on top of, and PHP's lack of generics makes this mostly impossible. I can't fix in userland what it misses in its stdlib.
3. A standard story for async and long-running code. Yes, I know about things like pthreads, curl_multi, amp and react-php. I never really felt like any of that stuff was really suited for mature production code and real-world deployment patterns, which is why I always ended up with architectures that boiled down to handing off anything long-running to a queue with separately launched workers processing it in series. I would like an extension to the standard PHP execution model and core language that gives a path towards fully non-blocking architectures as a standard feature.
Stupid idea IMHO. PHP is great BECAUSE it organic growth. It fully exposes the incorporated libraries with the same naming convention of the library functions and often additionally also in ObjectOriented style.
Have a look how green field planned ObjectOriented Namespaces in Java and dotNet Framework 1-4 turned out. Java's String vs StringBuilder vs StringBuffer, Java's deprecated Date and Time classes, the whole "old" dotNet Framework has been deprecated for a slightly incompatible new dotNet Core namespace and several namespace parts got deprecated long before, some got useless with the move to asynchronous programming (something C/C++ based WinAPI supported since 1994), etc.
What history showed us that monolithic namespaces designed by committee doesn't work out that well, an organic growth may look ugly to you but is easier to remember and quite sympathetic - I for one like PHP also because of that. JavaScript, C99, C++11, have a similar long term history.
Also PHP is so great because of it best of class documentation on PHP.net - no other language has such an extensive docu (and for so many years) incl useful comments on every page. JavaDoc, MSDN, MozillaWiki, etc are unfortunately worse in every regard. (MDN is catching up; and even W3School is quite handy)
You can't tell me that the fact that the opposite of the `htmlentities` function is `html_entity_decode` is "great, easier to remember and quite sympathetic".
Of course you need great documentation, with those inconsistencies users have to look at it every 5 minutes to even know what they're doing.
It's just you. PHP.net documentation was always better than the rest, easy to read, some simple examples and with helpful comments. JavaDoc, MSDN had no comments for decades, little examples and the later one lacked lots of API parts. Show me one online documentation of a language that is/was better. Also great are the book "Programming in C 2nd ed" and "Programming Lua", and the Golang focus isn't bad.
How is programming in PHP these days? I haven't used the language since 4.x-5.2 or so. I wrote it off completely when Hack and HHVM came out due to the nuances between it and PHP proper (not to say either is bad, it was just another barrier, and set of choices I didn't care to deal with). I typically write Ruby, Elixir, and some JVM based languages these days. Any new features or language changes that make it more pleasant or any good use cases compared to my usual languages? I will add using it anywhere, while a valid use case, isn't something particularly attractive to me.
Edit: just wanted to say thanks for all the good comments posted so far!
It's fine. I still write a decent amount of PHP. I also maintain a Wordpress-backed CMS that processes payments and it works just fine to the tune of several million dollars per year, a figure that most people on HN start planning for concurrency, scaling, and doing tons of premature optimizations before hitting.
I helped on the HyperPHP documentation team and debugged a bunch as I wrote some machine learning stuff in PHP as an exercise in developing it with the HyperPHP translator.
I enjoy writing it. I find myself using Python more and more simply because it's easier to find better outsourcers with academic projects in their background (a niche I'm in and something that Python was literally built to service), but PHP 7+ has been great. I don't particularly care for the unbridled hate that comes with PHP historically being "bad" and also extremely popular.
The biggest grievances stem from PHP wanting to please you and convert things from one type to another even when it really, really shouldn't. Adding variadics in 5.6, return and scalar types in PHP 7 tunes down this sort of crazy. Not fully, though. String comparison is still broken -- use strcmp() and be happy. Using anything else is dark and full of terrors. Well, at least it's not transitive https://3v4l.org/goSYX
Further, avoid == completely, pass the strict argument to functions that do comparison like in_array(). You don't want https://3v4l.org/mcpi7 to happen. You want https://3v4l.org/Yo6tI instead.
Your functions in 7.1 finally can typehint for iterable (array or Traversable object) although the array_* functions still only accept arrays. There are nice little libraries papering that over and installing libraries is easier thanks to composer.
PhpStorm gives you a fantastic IDE. The language is still ridiculously easy to deploy thanks to a zero share model.
Basically: most of the landmines can be cordoned off with putting declare(strict_types=1) on top of your files or bridged over by libraries like nikic/iter. A few are left but they are easy to avoid.
Does PHP have linters or something that force you to use the practices you described? I find in Javascript that works pretty well to restrict the language to a sane subset.
Pretty independent of recent improvements, but one thing I feel people are forgetting about PHP these days is that, when given to a good hosting provider, PHP is essentially "serverless" programming, but without the vendor lock-in stuff like AWS Lambda give you. (and without the hype)
Admittedly, even on a good host it won't scale as ridiculously well as a lambda function does, but I'd wager scling from 1 to 1 million req/s in an hour and then back again is a pretty marginal use of Lambda. All the other advantages boil down to not having to manage your own server. Just deploy the code, and that's it.
Well, PHP has had this for decades. And I believe that people should really consider this when choosing a language. I don't know of any other language that you can code a backend in without thinking about servers and daemons and keeping nginx up to date, without getting vendor locked-in to something like Lambda or Heroku.
This is also why I don't really see the point of Hack/HHVM for any new product: If you're going to install some random runtime on some server as well, there's probably more ergonomic languages you can choose.
I completely agree with you about the ease of hosting with PHP.
In fact, it's baffling that other popular languages for web development - such as Python and Ruby - have failed to address this issue of easy server installation. Developers underestimate how important this is.
If you want to sell a self-hosted solution to your customers, especially if they are small or medium-size businesses, it's impossible to offer an easy self-install solution using other languages (i.e. easy enough for non-technical users to follow instructions for install success).
Having a ridiculously easy web app installation process for servers would unlock countless opportunities for developers to reach more users or customers.
Programmer Jeff Attwood wrote about this in a critical post about PHP:
"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."
Attwood goes on to say we should:
"build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible." [1]
That was written in 2012. And yet here we are in 2017 and there is still no other language that matches PHP for ease of server install, or for choice of hosting providers. I repeat: developers underestimate how important this is.
This. When I got my first explanation of "serverless" (i.e. the details of the runtime and server are managed by the vendor for you) I almost laughed and said "Oh, like PHP on shared hosting."
I've wondered for years where else this aspect of PHP might be appreciated and show up in another ecosystem. In retrospect it almost seems obvious that it'd more likely appear in the form of convergent evolution combining another benefit that's higher status in the industry if less frequently needed.
Because if so, there's quite a few drawbacks. You're generally not in any sort of scalable setup, no high availability, you're on a shared box with other customers, you are susceptible to IO constraints on the shared disks, etc. You're still going to need a database of some sort for most applications....
> You're generally not in any sort of scalable setup, no high availability, you're on a shared box with other customers, you are susceptible to IO constraints on the shared disks, etc.
As you describe acceptable use-case for 99% of all projects.
I get your point but also consider that messing around with installing php extensions and using pecl is more of a nuisance than just deploying your node_modules via something like rsync. The php community solves this by writing polyfill which seems like wasted effort (writing something in php that already exists as a php extension)
PHP isn't serverless in the same way a lambda function is at all. You still need to host something that responds to HTTP requests and passes them along appropriately to PHP. Just because it has a share nothing model doesn't mean you don't need to provision servers. You still need to do 90% of the work.
I think he meant you can easily find $5 "unlimited" php web hosts. So for all intents and purposes it's serverless as in you can use it on a shared web host, where you do not have to manage the server because the hosting company does it. Not that it's literally serverless. Even lambda uses servers obviously. They just abstract it away which is what he meant. Clearly all cloud offerings are backed by servers, it's just abstracted away to varying degrees
For $5 a month you can get a Linode VPS with 1GM RAM. After the one-off learning curve of Docker you can image these servers and get much more for your money than what any shared hosting provider has to offer. Better still, you're not tied to PHP either.
You're missing the point. The shared PHP host can be $5-$20 per year and handle bursts in excess of 1GB (assuming you're not grossly oversold, which is also common in VPSs).
PHP - at least if you're working on a modern 7.1 code base - isn't perfect, but it holds it's own. You do need at least one experienced person to stop you making serious mistakes (and with PHP, there are a lot of mistakes to make!), but in my experience that's true of every language.
Syntax is still a bit janky, the standard library has function names and parameter orders that seem to have been created by feeding the source code through a blender, and nested ternaries are a trap for the unwary due to their completely broken associativity rules.
On the other hand, the syntax isn't that bad, the gradual typing story is starting to get pretty solid, composer is really nice, IDE support is great, and the ecosystem is stable, mature, and deep. (And you shouldn't be using nested ternaries anyhow, come on, this isn't a code golf competition.)
As a general rule, I find the project I'm working on now to be slightly more pleasant to work on than the Python/Django app I worked on before, and significantly more pleasant than any node app I've worked on.
Five years ago, if you told me you were starting a new serious project using PHP for the server side I'd have thought you were probably making a mistake. Today, I wouldn't blink, again, not because it's perfect or the best, but because it's solid and mature and good enough.
i think PHP has the opposite problem of JavaScript - a build-in function library that's too big and very inconsistent. much of http://phpsadness.com/ remains in v7+. i tried to get them to change their long-standing, self-admitted improper ternary associativity [1] or at least deprecate it in v7 but it resulted in a huge bikeshed (despite no one actually encountering code that depended on the wrong behavior which has been discouraged for many years) and died a fast death [2]. their "if it's documented [3], it ain't broken" stance is pretty toxic and they maintain BC to a fault, IMO.
also, they've refused to implement native multi-part formdata parsing in anything other than POST requests and dont expose a good/safe way to get this done either, leaving PUT/PATCH request parsing up to the users, which is shitty and has been asked for a long time ago [4]. this means you can't rely on language-level support for basic REST, leaving it up to frameworks/routers.
it's crap like this that moved me on to other languages. PHP7 is fast though, and gets shit done. i'll give it that. i don't see any reason to start a new project with it when you can have node/js/vscode (or better).
> i tried to get them to change their long-standing, self-admitted improper ternary associativity [1] or at least deprecate it in v7 but it resulted in a huge bikeshed
Oh man. Remember that drama in the internals when trying to remove T_PAAMAYIM_NEKUDOTAYIM ?
At least their reluctance to implement your feature requests for native formdata parsing seems to address your criticism that the built-in function library is too big.
they don't need to be functions. PUT/PATCH/etc bodies should be decoded automatically into new superglobals to match the existing $_GET, $_POST and $_FILES. if you're gonna have a shitty API, at least have a uniform shitty API ;)
Its good. We use silex/twig for development. Sites/ form processing is pretty straight forward and easy and I like the "microframework" idea of not being too opinionated.
Symfony and Zend have a large library with various functionality and you can pick and choose what you like.
The php Composer lets you control dependencies easily.
The main problem is that there are almost too many frameworks and the language has a bad reputation (legacy warts from old generations). I maintain java and perl websites too, and find the php ones easier to maintain.
PHP has some design decisions (e.g. shared nothing architecture) that used to be laughed about - nowadays it's obviously known as a big advantage - PHP can scale linearly with no overhead.
The syntax is inspired by Perl and C family (C/C++ and Java) and many functions one knows from C family are inbuilt. The advantage, it's friction free, hassles about memory management, dynamic typing allows rapid development, experience, etc.
The focus of PHP is all around the web, it was the first successful language designed for the web. All inbuilt functionality has been carefully selected, everything is built in and can be used from the start. You only need to copy the files via (S)FTP or SCP to the shared hosting server (nowadays it would probably be called "server less", e.g. Amazon Lambda) and press F5 to reload the page. It's basically the easiest environment to start, and can be Sean as the successor of Visual Basic 6 as the entrance for many younger devs after 1999 in the programming world. And the good thing almost all the negative cruft of the earlier era got removed with PHP5 and PHP7 (and the compatibility is still there, old PHP4 code still runs (or with minor changes)).
Today most languages like Python, Ruby, Perl, Java, etc also offer asynchronous frameworks to let them scale a lot better - compared to them, you don't have to change your code with PHP, it was always shared nothing and is fast by default - according to benchmarks often faster than Python, Ruby, etc.
Nodejs, Go and Java offer nowadays very comparable performance (with Java and Go being slightly faster) in common benchmarks and real world. Nodejs with (vanilla) JavaScript and PHP allow for faster development - no static typing, no compiling step.
Erlang/Elixir is the latest hype. Beside some different terminology and focus around functional language parts, actors model, the inner working of ErlangVM and e.g. HHVM are not so different. The shared nothing, one thread per execution model offers similar results. ejabberd XMPP server software written in Erlang and used at WhatsApp (now part of FB) revived the interest of Ericson Erlang eco system. PHP can handle such chat services as well, see Slack. https://slack.engineering/taking-php-seriously-cf7a60065329
Isn't Slack an example of a non-scalable architecture? There is a long time hard limit to the number of people accepted in a Slack channel (around 10,000 I think).
I've been using PHP for many years now and I was very close to switch to NodeJS or Go a couple years ago until I discovered Laravel. That changed my view of PHP completely and it improved my code quality and potential by a 10x factor at least.
I think that what Taylor Otwell has done in the last years with Laravel and with its ecosystem has been really underestimated. Not just for Laravel that is an excellent framework in my opinion, but especially with all the other products and libraries that he built along the way.
It covers all the needs I had in building my last few SaaS products and it made my life soooo much easier.
A few examples:
Forge and Envoyer: setup and manage your VPS in a breeze and deploy your code with zero downtime.
Spark: create a SaaS product in literally a matter of minutes without having to care about all the boilerplates
Echo: real time notification across multiple channels (mail, Pusher, Slack, etc.)
Passport: OAuth2 API server as easy as it can be
Scout: Redis/Algolia search with just a couple of lines of code
Dusk: test your app easily both for unit and browser testing
Cashier: payments with Stripe and Braintree in a breeze (both for one time payment and recurring ones)
Socialite: OAuth for all kind of services (Facebook, Twitter, Google, ...)
And beside all this, there is the excellent Laracasts by Jeffrey Way that made me learn not just Laravel but PHP and JS in general in a really great way.
And I could go on talking with the great and simple queueing system, the perfect integration with VueJS that I love as well, ...
As you can see I'm a big big fan of Laravel in general and I hope that it will become popular in HN especially over time.
PHP in general is easy to write. Philosophically, it's all over the map due to mostly historical reasons. People say that the current development team are making it better and I don't disagree. There's just so much you cannot do when the core is so shakingly built.
Still, most of the uglies of the languages can be learned and then circumvented in action or by using proper tooling.
PHP 7 followed the general trend of bringing stronger types into dynamic languages. You can now annotate function arguments with types. I believe that makes it possible to write a static type checker, but I haven't seen one yet.
Why people hate it? I cannot speak for the whole public, but I dislike the language because it let me down. My first experience with PHP is from 1998ish, when I saw it as a way superior option to Perl, and ported a web application to PHP.
After that, I learned about programming. I didn't touch PHP again until 2013, when I got a job in a PHP shop. I went there with an open mind, thinking that the programming language is one of the least important things when building products. But every step of the way, PHP somehow got in my way. It hadn't gotten better in ways I would've liked. It let me down.
Now, of course, I don't work there anymore, so the amount of fucks I give at the language is slowly declining. Soon, I'll be able to not care at all.
I can't answer your question, but I'll tell you why I didn't choose PHP many years ago for a web app:
1. PHP is very welcoming to beginners. That's of course a good thing, but the downside is that it's actually quite difficult to get quality answers on StackOverflow, which is rife with clueless trial-and-error answers and "Just use <completely unrelated heavy framework>, dude" kind of responses
2. PHP started out as a simplistic server-side templating/expression language; which is fine by itself, but without any kind of injection prevention is incredibly naive, and the reason for so many DDOS botnets. Of course, using embedded PHP (eg. in a processing instruction in your otherwise static HTML) hasn't been considered best practice for years. But then why use PHP at all, when this distinguished feature isn't usable, and neither is PHP a standardized language, nor is its stdlib any good. In fact, this retargetting of PHP with little or no architectural oversight (from an expression language into a full-blown app language with OOP and whatnot) seems endemic in the PHP world, and is also the case with eg. WordPress.
That said, I quite like the PHP community for their practical-mindedness and their get-stuff-done mentality.
"Welcoming" is not a good thing. The worst thing you can do with a bunch of clueless people is make them prolific at writing code they don't realize is unreliable. We should be teaching the minority who have the aptitude and turning away the rest.
My biggest complaint is that it's associative arrays are different than objects. So serializing and unserializing json can become a nightmare. This is easily circumvented by being careful to be consistent. But big libraries like symfony will change your json around and break things. In node it's just not an issue
I left the PHP world a few years ago, but I still have to go back occasionally to manage a few old projects. I recently upgraded one to PHP 7.*. It's soooooo much faster than older versions I consider it a must have for anyone working on PHP.
That said one thing I don't regret is not having to deal with composer again. It's basically a shittier version of npm, with a fraction of the speed and a fraction of the logic built in. I have projects that have installs that aren't idempotent due to weird composer caching issues. Composer is a good thing but I can't help but wonder if PHP simply isn't fast enough of a language to build a package manager in.
It's weird for me. I used to write both Java and PHP in the past.
Custom PHP framework we built took into account the way PHP is executed: you are stateless and need to setup everything on every request (runtime is fast to start with FPM and opcode cache). Namespaces based cheap autoloader worked great. No composer. We used singletons for getting the configuration and connections to DBs. There was almost no setup code that needed to be run every time other than loading .ini based configuration and connecting to the DB. Our webapp responded under 20ms (DB and Sphinx included), and I could get it to respond in 1 ms for things where we needed to be quick and didn't have to output HTML with Forms. I was really small and you could read the whole framework code in 1-2 hours. It worked with SQL in a reasonable way. You didn't have to write your SQL for simple CRUD, but for larger things involving joining multiple tables and more complex expressions we wrote native SQL.
I switched jobs, and started with Symfony 3. The thing felt like some Java framework, but poorly documented and harder to use than it should be. It had lots and lots of setup code done before handling every request. There's a whole DI framework with it's own tons of setup code for every component. And you have to do setup even though you don't use the component in that particular request. There's ways of doing lazy setup, but you still waste time to wire that up. Framework overhead can be 30-100ms. Other modern PHP frameworks have similar overhead. I know that there's PHP-PM, to save some of that work that isn't really $_REQUEST specific.
Everybody is using type hints wherever they can, and it feels as verbose as Java, but without compile time type safety, and you can't really put type information everywhere (class members for example).
Even though PHP runtime has made great progress (it's probably the fastest interpreted language, and it's great it has reference counted garbage collection), it feels like language is struggling to find it's identity, with it taking a lot from Java and still coping with ugly legacy ($, having to use $this inside a class function, php.ini, features for supporting templating even though it's rarely used as a templating lang in modern frameworks).
Doctrine and it's verbosity feels very ugly to me.
Learning Python and Flask (as an example) was much more enjoyable than switching from a nimble custom PHP framework to Symfony.
I'd argue you can write fast, simple and maintainable PHP, using state PHP runtime has setup for you ($_POST, $_GET, $_SERVER etc), namespaces and a namespace based autoloader, trying to use pure functions when you can (using static classes shouldn't be a sin - just to split your code in sensible parts), and using general good practices for writing readable and maintainable code (avoid long functions, huge classes, too much block nesting, decoupling, naming things in a good way). With some conventions you can write a decent and productive framework quickly, but you could do that with a nicer language too, so what's the point?
I switched jobs, and started with Symfony 3. The thing felt like some Java framework, but poorly documented and harder to use than it should be. It had lots and lots of setup code done before handling every request. There's a whole DI framework with it's own tons of setup code for every component.
This is also the overarching feeling I get from the big PHP frameworks: Java envy. They picked an architecture which is perfectly sensible in Java, but slow by design in PHP. You also notice this in the language features being added, where gradually PHP is turning into Java. On the Java side instead there is Scala envy, with Java slowly turning into Scala.
I don't mind PHP taking good ideas from Java though, PHP 7.x is much improved and the community overall seems to be moving in the right direction: take the good ideas from Java, without taking on the worst excesses.
Drupal and Symfony have inherited the worst excesses of Java's AbstractSingletonProxyFactoryBuilderContainer culture. Laravel and Symfony also have a preference for docsting annotations which are even worse than Java.
PHP7 has improved life when dealing with legacy systems, but I think all in all you're better off not building new stuff in it. There are almost always better tools for the job than PHP, like Django, Rails, Go's net/http, etc. depending on the kind of thing you're writing.
It depends. I'm way more proficient in Python than anything else, but I'll still reach for PHP fur a single page template / dynamic report, or awk for some jobs, bash for others, Perl if there's exactly the right CPAN lib, ditto ruby or node, c for some jobs...
Some times a different language can so utterly change/simplify your approach to a problem it's 100% worth it.
If you don't do very much stuff, then sure. But most people end up coding long enough that learning new things is well worth the time. It's not like it takes more than a few months to learn a new framework or language, and you get benefits beyond just the new tools.
Visual Basic is still a language that many people know better than other languages, but I'd not advise those people to stay on VB just because they know VB. And PHP is getting a fresh coat of paint but that doesn't mean it isn't antiquated - what other web based programming environments provide a CGI model where scripts are in the public directory? How many of them are HTML with directions for the actual programming language?
If PHP is intended to stand on its own as a web development language, they've missed a few bits of low hanging fruit already. Like, take HTML out of the language. Package PHP with Composer. Allow for a new app base model where apps have their own FCGI servers and routing is done in PHP. I mean why not? These are things that modern users of PHP already try to accomplish, sometimes with [ugly hacks that are prone to security issues](https://www.acunetix.com/vulnerabilities/web/nginx-php-code-...).
I don't care if people think I'm just being a hater for the sake of it. I really think PHP is a dead end, and I think that because it seems the focus for PHP development has been toward making older software like MediaWiki run better rather than make PHP a better platform overall. As far as scripting languages go, it has a history of confusing, non orthogonal behaviors, legacy cruft, bad documentation, and designs that promote or directly cause security problems. And it has such a problem with memory management that the gold standard is to simply kill the PHP instance every N requests.
More like, all you need is a Swiss army knife, and there are dozens of different Swiss army knives that can all get the job done. So use the one you are most familiar with.
You can get it to work with a $5 a month VPS. The issue is more that a VPS requires constant maintenance.
Let's say my friend runs a store. He needs a website. I can:
1. Find a $5 a month shared hiding plan. As it's Shared, they don't let you start servers, so go (as well as python) is out of the picture (unless you run it as a CGI - yuck). You develops the site, sell it to him, and fix on contract. You never have to do another thing for him.
2. Get a $5 a month VPS, spend another $1 a month (or more) on an S3 backup. Ensure said backup works (try it out once in a while). Keep OS up to date.
Which is easier? Which is more maintainable?
Does anyone think that if WordPress was written in Python it would get nearly as much traction?
That's why PHP won the internet (and that VPSs were extremely expensive until a about a decade ago) - servlets where around for a long time but you couldn't run it on a shared server - made it dead on arrival.
And then after you move on, be cursed for all eternity when they have to find and hire someone with go experience to fix that tiny bug. Costing them 3x as much as if it was just PHP where anyone and their brother can work on it.
This is exactly the type of response I expect from people who have never done this in real life, because real small businesses don't know what to do with that linode VM, don't know what docker is, and will end up undoing it all the day they need to make a 2 line text change and their neighbor who makes those changes for them in notepad can't do it anymore
I haven't built anything in it (and rarely touch PHP, aside from some Wordpress ecosystem stuff), but if I were to build a web app in PHP today, I'd build it in Laravel vis-a-vis "raw" PHP.
In addition to PHP itself undergoing a lot of good optimizations a lot of tooling and frameworks have come a long way as well. Composer and most modern frameworks play much nicer in the ecosystem and it is quick and easy to get something up and running which gives access to most of the things you'd need in a webapp. I'm a big fan of Laravel personally but there's plenty of other great options nowadays.
It's not a terrible experience, but it is truly baffling that anyone would start a project in it today. A good static type system is too useful and important.
That's the last thing I look for when evaluating a new language.
Well, actually I came to dislike static typing so much that's a big point against languages IMHO. I concede that it would have saved me time with data occasionally going to the wrong argument/method/function but every time I understand that I'll have to type almost useless stuff like Map(<String>,<String>) I hit back and return to HN home page. Moving to dynamic typing was as liberating as moving away from malloc/free to garbage collection.
I think I could stand languages with implicit typing. All I want is not to have to annotate my code. I'm happily paying some time and tests for that.
Btw, I don't like people downvoting to express disagreement so I'm upvoting you. My +1.
> A good static type system is too useful and important.
What? A whole lot of web apps these days are built in Python, Ruby, or JavaScript, none of which are statically typed languages. Do you mean a strong type system?
I assume mean strongly typed and I can agree with them to an extent. While it does add slight overhead when writing code (not enough to matter I think) it does help eliminate a bunch of errors/edge cases you'd have to unit test for in an dynamically typed language.
Though as I always say: use the right tool for the job. And for a lot of jobs dynamically typed languages and framework offer a lot to the developer.
I still do my saas projects all in PHP. I mean, I'm not building NASA control software it anything, but I have incurred very few problems due to dynamic typing. Not to mention the fact that I can hire php devs for half of what a ruby dev wants these days.
On my 4-year-old Macbook Pro PHP 7.1 parses a 19Mb log file with the regex "\b\w{15}\b" 5 times faster than Python and Ruby. It's even 3 times faster than Perl which is hard to believe given Perl's insanely fast startup time.
Regex engine for all of those languages are coded in C, so that's probably not a good benchmark. That said CPython and Ruby MRI are slower than PHP5, so yeah PHP7 should be even faster.
Is there a PHP modding squad in Hacker News? Legitimate, non-offensive anecdotes are getting downvoted in this thread while all positive comments are being upvoted.
I think I've seen such a trend rising in the past few years, but I wasn't sure: every thread covering PHP in some way gathered a crowd that defended "how PHP is much better since 5.x" or referred to PHP being hated by people without any good reason.
And yes. This very comment got downvoted to 0 in less than a minute from its submission.
PHP folks are a perfect case of the blub paradox and they are sadly always looking up. PHP isn't treated with the respect it deserves. PHP powers large parts of the internet, from tiny to huge projects. But there isn't even an attempt to understand what it made/make work so well. PHP is quite different from other languages but instead of curiosity from the competitors, there is just bad reputation and ignorance. The community and language itself constantly leans and evolves towards other languages. Ruby, Java, Javascript and whatever. The shortcomings in contrast to other languages are often drawing much attention in the community and in my opinion is overshadowing PHP's strengthes. Much of the recent changes in PHP have been a kind of fanservice to appeal the users of other languages. While this isn't particularly a wrong strategy to stay around, it caused an addiction to be more similar to the competitors. PHP lost it's identity and got unknowingly angry about it.
This is just my opinion and there are some wrongs here, but thats how I would currently explain the sub par PHP community behaviour.
$x == $y should guarantee that $a[$x] == $a[$y]. In PHP, it doesn't. That's not different, that's just broken, and the language design makes dozens of elementary mistakes like that where getting it right wouldn't have sacrificed the only strength (streamlined deployable server integration) in any way.
it's really astonishing to see PHP still alive and kicking, despite all the backlashes it has received over the years. whatever it is they are doing, they must be doing something right.
Long time PHP dev here. Note: These are my personal observation and opinion.
The usage you see are mostly from people already invested in PHP. However, I'm starting to see fewer new PHP devs. Some of the talented devs I know of have migrated to other "cool" languages. There are fewer PHP jobs than they use to be. I also observed less activity in PHP related subreddits. Its position as the #1 web server language has already been taken over by nodejs, and the remaining chunk eaten by Go, Python, C# (as ms tech goes open-source) and other languages. I dont see PHP going away anytime soon, but I dont see it gaining more users over time.
> Its position as the #1 web server language has already been taken over by nodejs
How so? Because when I put a PHP script on a server with "<?php echo 'Hello world' . date('Y' time()); ?>" that is a one-liner and I'm sure it'll work for the next 20 years.
With nodejs, I have to implement the whole webserver and then my web app is also a server, even if it's "only" 20 lines of code and I need other tools to make sure that this server never crashes or automatically reboots and all that stuff.
Imho, the main benefit of PHP is: You can write a script today and because the language is mature, it doesn't change all the time and you can be quite confident that it'll keep running for another decade.
> How so? Because when I put a PHP script on a server with "<?php echo 'Hello world' . date('Y' time()); ?>" that is a one-liner and I'm sure it'll work for the next 20 years.
Web hostings have abstracted this for you. In reality, you need to install Apache or Nginx first. PHP does have a built-in server but its for testing only not production.
Nodejs is both a server and a webapp. You just need to install nodejs at bare minimum to run a "hello world".
Try installing nodejs and php on DO to see what I mean.
With regards to nodejs overtaking PHP, various stats from various sources back this up.
> it doesn't change all the time and you can be quite confident that it'll keep running for another decade.
Now thats just false. The switch to PHP7 from PHP5 alone has many BC breaks. Latest Drupal is a rewrite. Laravel LTS dont last "a decade". Code breaks all the the time in PHP land. The only thing that dont change in PHP world is WordPress.....
You can't have it both ways. You can't pretend that backend web development isn't software development when it's convenient and assert that it is when it seems prestigious.
Your example doesn't account for any complexity. All it seems to say is "You don't have to think about architecture or platform, you can pump out thoughtless abandonware with ease."
With PHP you also need to implement a webserver (Apache), so you're one-liner is also actually not a one-liner at all.
Also, pick the right tool for the right job. Who writes code these days that silently sit still for a decade? Hardly anyone. And even if you do, I don't think Python or Node will suddenly stop working (as you're implying).
I don't know, but I didn't like my PHP years and it wasn't mostly because of the language.
Almost every PHP dev I knew did his own CMS and they were mostly horrible blobs of code and the "big" projects weren't any better. TYPO3 and WordPress were a mess and they were considered the industry standard...
I worked with code-bases that had files with 10k lines.
Everyone had to reinvent the wheel and all were bad.
It was like when someone started programming, they read somewhere that PHP is easy and so they started with it and since it was so easy to get the first "dynamic page" in the wild, they didn't bother to learn much about software engineering and even those who did simply followed the patterns blindly and ended up with the same mess, but different.
Somehow Node projects do better and I guess it's because there are more resources out there to "really" learn how to do things. On the other hand I have the feeling people are getting less independent. Some are crying for better docs or tutorials, while I figured it out while reading the source or browsing a few minutes on issues.
15 years ago (when, BTW, Python was already a thing) you _had_ to use PHP, unless you had extra money to spend on a more "scalable" technology (so enterprises, who had money, frequently chose Java). It was a monopoly like JS was/is a monopoly - you want to write code for a browser - you'd better know JS. Now, between AWS and DO, you can with relative ease start up in Go, Node, or Python, and there's no need for PHP.
I fully agree. Its all about how to do x stuff at y cost. PHP served a market segment. Now the other languages can do the same, if not better, at the same cost.
To expand on thing-ness, the first public Python release was 26.5 years ago.
15 years ago Python was already 10+ years old and was a very popular language.
Very long time php dev here. What you are seeing is the relative fall from the crowd that moved in after the facebook social network movie. Much of the php hate started around this time. Over the last year people are moving back because of things like Laravel, composer, PHP 7 and issues in other languages. Will take 4 years to reach a peak.
Yes, if you search Indeed.com's API by job title there are currently more Node.js jobs (384) than PHP (268) in London (excluding WordPress, Drupal, Joomla & Magento).
I'm not sure that's entirely fair; a lot of those jobs you've excluded will be serious PHP coding jobs, not just "install and configure a plugin" sort of things.
There'd be a lot fewer node jobs if you managed to exclude all the ones that used express. :)
PHP's problem IMHO is that I wouldn't be able to use it if it wasn't for autocomplete: inconsistent function names, inconsistent parameter order.
The ecosystem is fine, there's Composer, PSR, Laravel. The problem is PHP's legacy.
I wish someone created a PHP class one could use to namespace sane function names and parameter order:
EDIT:...and here it is: https://github.com/nkkollaw/php, discussion here: https://news.ycombinator.com/item?id=14885226.
Pull requests welcome :-)