I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that.
I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much.
If you're programming in PHP, you're not running around talking about "convention over configuration" giving talks, or trying to make your code beautiful. It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick. You're failing while the other guy is still updating his gem file. You're advertising while the other guy is trying out some fancy new deploy script. You're incorporating feedback while the other guy is just starting to get to work. When he finally fails, he's used up half his runway, whereas you, the guy who didn't give a fuck about your code has gotten past that first failure, and are finally getting some traction.
Hopefully, the next guy to join the company will clean up your shit. The other guys code may not look like shit, but it doesn't solve any useful problems... so they never got the chance to hire that next guy.
Some companies are succeeding in spite of php. There are many, many users of php, and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum.
It's easy to cherry-pick the winners and miss all of the tremendous losers who picked php and got nothing for it.
It would be an outlier company indeed who held an 'all hands on deck' meeting and said, "We're succeeding in spite of PHP everyone!"
Only engineers care about programming languages. Seriously. That's it. No one else cares about them. I work in a large public university alongside a revolving door of student interns who are always 19. In 10+ years of work, I've still yet to meet the person who talked about their favourite website or app, but lamented that it was written in Php or JavaScript or Go or Java. It's only us (the HN'ers) who fret about this.
Don't believe me? Imagine the look on everyone's faces at the tech publishing houses around 2009 when books about Objective-C sold a few hundred copies a year to doing tens of thousands per month when the iPhone rocked the world. This happened without a proper language hot stove on Hacker News, no?
People care about outcomes. People care about products. People care about being dazzled. People care about showing their friends this incredible thing they saw on the web/this new app.
Brian, do you have any examples of companies that failed using PHP that you think would have succeeded with another interpreted language, and what problems did they run into that gave you this judgment?
Asking as I've developed in a slew of languages and never found the PHP-bashing credible. Most of the complaints seem to come from Rails people, but there are no shortage of MVC frameworks in PHP, including at least one that is a direct clone of Rails.
True. But they might have failed with any other choice. Technology is overrated. Yeah, it matters, Yeah it helps. But the right foundation won't save a shite product.
Delivering enough value to users, faster and cheaper than the competition, wins.
The language you use pay second- and third order dividends, but most battles are fought and won on first order.
I'm a C++ developer, have shipped Java and C# and Haskell and Python and a bunch of other code in production.
If a friend asks me to spin up a website for him/her quickly, I'd still do it in PHP.
I've gone one step further and created a template:
Some companies are succeeding in spite of [insert language]. There are many, many users of [insert language], and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum.
It's easy to cherry-pick the winners and miss all of the tremendous losers who picked [insert language] and got nothing for it.
Precisely. This is classic base rate fallacy. If tons of people use PHP because PHP devs are cheap, there are bound to be a ton of successes despite the fact that it's a horrible technology in many respects.
> If you're programming in PHP, you're not running around talking about "convention over configuration" giving talks, or trying to make your code beautiful. It's a garbage language, and you know it.
This is exactly right. The right philosophy for PHP is to embrace the garbage. When you're done with a request, and have spit out all the HTML to the client, the server is going to throw everything away. So don't build a beautiful object tree to describe everything, just do the minimum amount of work to take the garbage input and generate the garbage output, and be done. Don't worry too much about your code being beautiful, because it lives in a dump.
This may sound negative, but working in a dump means you don't have to worry about appearances while you do what you came to do. You can always take a shower on the way out :)
If I wanted to embrace garbage every day I would have skipped college and went straight to being a bum. Life is too short to "embrace the garbage" every day.
> It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick.
PHP didn't succeed because of the "language" part. It succeeded because it was limited and focussed to just being a tool to write small web-apps in a short time.
It did one thing and did it better than anything else of the same era (I built CGI apps in C, Perl and Python before discovering PHP).
It was just files, that you ftp-d in and it just worked.
99% of the friction is in writing the first thousand lines of code and PHP meant that nearly all of those lines was business logic, not unescaping POST data or parsing GET parameters.
PHP doesn't remove your ability to think clearly. It is true that it does not provide helpful additions for algorithmic work, but it does not put challenges in your way when writing web-apps. And yet, it does not force you into too much magic about how it works - just enough abstraction for a messy coder.
I'd argue it succeeded because it didn't require you to run a server. All those cpanel lamp ISPs mean sign in and upload code.
All other solutions, java, .net, node, python, Haskell, etc require you to run and maintain your own servers. A minor exception for CGI based solutions but those were all too heavy.
This comment just nails it. It is perfectly possible to have a well written code base in php. I don't understand whatever written in php is shit.
Some good programmers genuinely point out some of the pain points of php, but most programmers paint php as shit just to show off as a good programmer.
> It did one thing and did it better than anything else of the same era
I would argue that it still does. It's not a great language, but to just get something working I still can't think of anything better that doesn't require lots of planning or infrastructure
So much time wasted talking about the "right" way to build software, and the best technologies to use, taking positions to bolster your CV or make a name for yourself, and nowhere near enough emphasis on shipping useful, working software.
It drives me slightly nuts. Many people don't realise that technical debt is often a great problem to have because it means you've succeeded. They also want to live in this reality distortion field where they ignore the fact that the code they write today is tomorrow's technical debt because, for reasons I don't fully grasp, they think they're going to do it "right" this time. To quote from Garth Marenghi's Darkplace: "Uh-huh? Bye." In 5 years' time our successors will be wandering around moaning about the crappy code we wrote today, but only if we succeed.
If PHP is the fastest route you know to releasing something worthwhile then more power to you.
(Just to be clear though: I'm not advocating an end justifies means approach to all areas of life.)
Eh, you can do rapid prototyping-type garbage code in any language you are proficient in, as you can do the endless-architeture-meeting, special snowflake beautiful code, enterprise-level everything documented and automatically tested continuos integration and deployment to the most popular containerized/virtualized environment for a reasonable price of $millions in PHP or even bash or powershell.
V1 is usually shit in any language and if it does what it's supposed to do, it remains shit forever. I've seen shit in C#, Java, and ROR. I've seen stored procedures stringed together inside MSSQL Server vomiting HTML snippets and PS shells giving birth to Excel files to be consumed via network share by some poor soul pressing a button in Excel. I've seen systems written in "enterprise" style, by "enterprise" developers without a single automated test and 20+ levels of abstraction with cross-dependencies running like spider web among 10-some "sub-projects".
I'm not even talking about time-tested shell scripts you can find included by default in your favorite distro or the widely beloved ./configure.
I guess the point is, the language has nothing to do with the attitude of the developer / project manager / product owner. It's easy and convenient to just dump your problems on the tool you're using, but the reality is more deeply rooted in the whole approach to software development (just get shit done), project management (the requirements have just changed, dude!) and the general "i need it done last week" attitude of the product owners.
But sure, let's collectively shit on PHP, just because it's easier. Just like writing shit code is.
I work in C# every day. I love the language, I love Visual Studio, I love the application lifecycle management features of the ecosystem. There's very little I don't like, or at least understand.
I started my career as a PHP developer. Any web project you prototype in C# could be prototyped in PHP in a small fraction of the time.
After I use both php and ruby for the same employer over more than a year. I would rather say Ruby is more like a garbage language -- 1) twist syntax to allow people write the same function into different ways is not a cool feature, it is disaster feature which causes more for a team to sync. 2) Duck typing is not interface, don't kidding yourself. they are totally two different thing. 3) ruby attract a lot of master level people try to make the community better, however, the whole community filled with mediocre developers who cannot even understand Rail != Ruby, and also they believe ActiveRecord is the only persistence layer they can use, and stop learning write native database query script.
Finally, good luck with writing a unit test against an API not created by you because, you have to go through deep into the source code just for figuring out what data structure return and give.
I have worked on both (among many other languages) and I too prefer PHP, but I guess my opinion on Ruby is unfairly distorted by Rails, which I dislike a lot. I hear that Sinatra is nice, for example.
I think you are expressing some legitimate opinions about what kind of languages you like. Ruby, like Perl, embraces more than one way to do it. Some people like that, others find it irritating. Neither reaction is wrong. I think the same thing goes for your reaction to Ruby's lack of explicit interfaces. I find it liberating, you may not.
However what I find incorrect is the claim that Ruby is a garbage language.
Then again, maybe that is best treated as hyperbole, as an exaggerated expression of your dislike for it.
I agree with this as well, although this is about Rails. I still have a legacy project to maintain in Rails (a big project) but that is (hopefully) the last I see of it up close in my life time.
I don't like the term "garbage language". People use to praise languages like Ruby or Python which don't even have private fields or type hinting the PHP has. Ruby libraries use approaches like monkey-patching classes in other modules. And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"?
Javascript actually has less problems than PHP. It also has proper lambdas, true lexical scope, and a shockingly good (if slightly confusing) OO system.
There's a reason that people claim (incorrectly, but still) that somewhere inside of Javascript there's a Scheme dialect, desparately trying to get out. This isn't true, but the proper lambdas and scoping are very scheme-esque.
> And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"?
I think JS is better than PHP, at least when it comes to: 1.) consistency of std lib and 2.) type casting. There are many surprises with PHP's type casting. See /r/lolphp sorted from top all-time: https://www.reddit.com/r/lolphp/top/?sort=top&t=all
I can sign below your post as experience of PHP developer who "fights" each day with bad code written by PHP devs. There are a lot of frameworks like Laravel, Symfony or Zend which introduces a lot of conventions (folder structure, naming, PSR autoloading built-in functions, resources) but it is so often skipped to "get shit done". I would complain on many aspects of daily PHP-development like not using tools like the PHP-MessDetector (one of the rarest tool used by PHP programmers), PHP-CodeBeautifier (phpcbf) or PHP-CodeSniffer - Hopefully some open-source projects started using a StyleCI. Another things is database-related code. PHP developers tends to use ORM lately, but on five projects with Doctrine in 4 developers used it improperly messing with a 1000+-lined classes and storing annotation above the fields instead of file or even using Doctrine to get native database-connection via PDO driver to use query db with SQL only instead of DQL for any case. In google there is enormous list of articles about PHP optimization - the interesting thing is, that almost any touches the fact the PHP application should be "compiled" (cached) (e.g. for Laravel [1]).
Whatever I would say about PHP - how good or bad is - I am almost forced to use it - In central/eastern europe almost any company uses it to develop web-backend... but I really would love to jump to Node/Go/Golang-based development team (maybe even remotely).
To be fair, as a Python dev, I have inherited some real crap in Python as well. Though recently I had to import some data from a PHP website we have - boy that was another level of crapness (though the main problem was the database design, or lack of it).
- You sit in a dining table with 50 different utensils. White wine glass, red wine glass, water cup, salad fork, dinner fork, dinner knife, teaspoon, soup spoon, bread plate with knife...
- When the food is served, you take the food, drop it on the floor, eat it with your face (not even using your hands).
"get shit done"... use spoon as a knife and knife as a fork, or try to sniff your food through your nose instead of eating it.
This sounds like to me you are mistaking the popularity of PHP with the proficiency of the developers. PHP has been around a long time and is used by lots of people. Even if PHP projects only have a 1% success rate and haskell projects have a 20% success rate, guess which one will have more "successful projects".
Accumulating bad code is like pushing your company from a plane without a parachute and hoping that the next guy creates enough cushion in time before the landing destroys the company (not the fall that kills you)--you survive because you are likely moved on and are busy pushing some other company to its doom.
It is probably ok if you work for a startup that does not survive long enough for the quality of your code to matter anyway. But in a regular company, your attitude creates a time bomb when eventually any apparently simple change may destroy the codebase (and at best, it just takes too long to make any change).
When someone (maybe me) comes and rips out my bad code later, they're going to have the benefit of future knowledge. I don't know how my code will be used in 2 years and what the requirements are, but they will, because they'll be there.
I do my part today by acknowledging all of my code is bad, therefore I don't invest a lot of time or ego in it. I try to make it in reasonably sized pieces so it's easier to rip out later (this may make it slightly less bad). If someone comes and tells me my code is terrible, I say yes it is, you might want to consider these things when you replace it.
EDIT: my opinions on this would change if I were shipping code to run on other people's machines: it's generally easy and quick to fix my code on machines I run, but updating code on other people may never update, you need to try harder to get it right the first time.
Amen. The ironic thing is most people believe that the fashionable language/framework du jour they're using in their project is "high quality code" that will be maintained like that forever, while turning their nose up at PHP code that is "disposable" but in reality more likely to outlast.
I can agree that php might not be the nicest or the fastest language, and I like to say choose the right tool for the job, but writing it off just because it's php is stupid.
A couple of months back there was this php sucks article about being looked down upon because you do php for a living. Php is the language people bitch about to feel better about themselves. Even within the php community symfony developers don't take drupal developers seriously. It's sad really and even I'm guilty of doing that. A little more respect for your fellow developers is all we need. It's like judging a book by it's cover. How would you feel if <insert your fav lang> was treated that way.
Php has a lot going for it. The community is very active and passionate, new things come out at a rate you can keep up with. You can easily get passionate about it if you engage in it.
A lot of interesting projects are (being) build with it and it is obvious that php won't disappear anytime soon.
If you have to work with php and bitch about it, make the effort and solve the problem you have with it. Contribute back to the community and experience the gratitude. You'll enjoy your work more.
So there are php people that care and they try to make the best of it. I don't think they consider it to be a garbage language. They are the ones that made php what it is today which is something totally different compared to what it was years ago.
But business success is largely orthogonal to language choice. I.e. when you buy a paid Github plan do you check what language they write the site in?
Of course a strongly typed languages should tend to have less bugs and that will save money. But saving money is only useful for those with revenue to being with.
There are a number of successful startups and very large companies using Haskell. It's understandable why it isn't a common choice, of course; the potential employee base is fairly small.
Not everything can or should be well engineered. People that always chase this are worshipping false gods. Does anyone have experience working on something that at one point actually met with the high ideals a certain mindset strives for?
PHP also has IDEs, tons of tools, tests, and gets deployed with many services and scripts. It's an inconsistent language, it's used by newbies in a very bad manner without even understanding the bare fundamentals of HTTP, but I really wouldn't call it a garbage language. If it were, it would have been dropped ages ago.
But I see what you're getting at... if you need to whip up something quick, don't start experimenting with the "flavor of the day" language or library.
This seems to assume that a developer necessarily hits an MVP in PHP faster than in other languages. This might be true when comparing with the tooling/dependency nightmares of JS/NPM, but a half decent Python dev can get a Flask app up and running in about 15 minutes.
I read the post as saying that PHP self-selects the kind of developer that is great at making an MVP, thus why so many companies and projects are written in this garbage language. I don't think the post intends to implies that other languages are slow to develop, just that their developers are.
You can have the same mentality in many languages that suck less than PHP, though. Python, for example, tends to get out of your way and just let you write your algorithm. Go, as well. Or various JVM languages, particularly Java 8 and Kotlin.
The one thing you want to avoid are communities that argue about "the best" way to do things. Even then, you can use the fruits of their labors, as long as they're willing to package it up in something that gets out of your way and lets you get work done. You just need to take the language but not the community.
I do think certain languages are more conducive to the "just write it quick" mindset. I find it easier to enter this mindset when I write a bash script.
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Products fail. Languages solve problems. Business domains have different problems. PHP won't solve a telecommunication challenge at scale. I believe in polyglot development. Choose the language and framework that suits the challenge. Not all shoes fit.
I think this overly dismissive/elitist approach is part of the reason why alternatives failed. Couple that with the ridiculous claim that a developers' time does not matter.
Up until the mid-2000s, if you wanted an easy up-and running web application environment without paying Microsoft, PHP plus MySQL was the only game in town. There were alternatives, but they invariably involved maintaining your own server and doing quite a bit of legwork yourself. The was no Heroku, no AWS, and tooling for python, ruby, and other environments required much more expertise to simply get an app responding on port 80.
Almost any big app you can point to that is built in PHP today was bootstrapped in this environment.
I did a lot of PHP from the late '90s up until 2008. Maybe things have changed in the intervening eight years, but I cant say I miss it.
I would never have agreed with you before, but I just came from a place where the fear of using something that was not sexy just paralyzed most of the developers at the company. They spent more time talking about new tech than implementing it. I've sworn off PHP, but at one point there I would almost have preferred they suggest we use it, if only to get something shipped.
Now I don't fret as much about unsexy tech. I do still advocate for new things when they make the team more productive, but I hope I never have to work at a place again where the latest and greatest stuff is used and people get nothing done.
> I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much.
My perception of the Clojure crowd is the exact opposite. They seem to be a bit too in love with the process and craft and not enough with the end results. That being said, I'd much rather code Clojure as a day job (I promise to be market focused!) than PHP. Right now I am almost all Python. There are definitely a lot of Python folks who are too much enamored with the craft, but the crowd is so big there's plenty of room for the GTD folks.
So people who don't care make successful projects and PHP is a garbage language that is responsible for more successful projects than any other server side scripting language. LOGIC.
My point is that the people don't care about the tech. They're worrying about the problem they're trying to solve. New companies that priotitize tech over finding and pleasing their customers don't live long enough to see the benefits. Just my observation. I've been through the "but if you don't build it right today you'll have to build it again tomorrow... that makes no sense" phase. I made some great code, but very few people are running it. My worst code is the code the most amount of people are running... it's because I got it done, and I got it rught before my budget ran out.
This is so true from my experience working for companies using PHP. You can advocate all you want to clean up code, but in the end, if it doesn't create a new feature its not going to happen.
I used to be this guy, ie, who cares but not too much. A big reason why I switched to node. Let's me think less about code (JS everywhere), and more about the problem at hand.
I like to call myself a "biztech" entrepreneur and these are the reasons I stick with PHP. Specifically using Yii2 I've been able to whip up MVP's and simply just focus on getting traction. In my experience that is all that matters for a startup.
Most of the cited successes were savvy early movers — every company mentioned aside from Slack itself is at least 10 years old. In the more mature, more varied tech space of today PHP seems like a non-starter.
Maybe it's just me but I do find a certain elegance in PHP. It's not beautiful by any stretch but it's extremely functional. You get the impression the Borg would use PHP. It's not pretty and it's not shiny but it works every time and it's extremely easy to work with.
I think this also could be that founders don't care about tech and Php developers are relatively cheap. Engineer experienced with different technology could easily get MVP of high standard in comparable amount of time but that costs money.
PHP isn't quick. It isn't faster than other languages. It's just a tool, and if you know how to use it well, it will be faster for you.
If you want fast, build a static site. If you're iterating on your builds and doing something non-trivial, pick your tools carefully but don't be afraid to try new things.
> "The next guy to join the company will clean up your shit"
Is that acting in the best interest of your employer? or ripping your employer off? I think more like the latter.
Imagine if other professions behaved like this, like finance or legal people. But suddenly because you are an "engineer" this is acceptable? If I was your boss I would fire you immediately.
The world of difference between balancing trade-offs in technical debt, tradeoffs in long-term/short-term goals, and deliberatively sabotaging the company by leaving technical debt for other people to clean.
You are a liability to the company and its culture. And you want people like you and your language to be taken seriously? that's why nobody wants to work with people like you.
The next sentence tells you where I'm coming from, but to expand a bit... here's my theory of software development in the point of view of a new company. If you have an existing product, you're already in phase 3...and sometimes phase 3 rebuilds the product. This does not apply... you already know what the software is.
There are 3 phases:
Phase 1: Initial development - Your goal here is to find the value to your user. Any code you write here should be considered disposable. If it's not valuable to your customer, it's not worth building right... if it takes time before you know it's valuable to your customer, it's not worth your time. If you're writing it to support millions of users, and you only have 100, you're wasting your time. In phase 1 you're concerned about creating revenue, and nothing else matters. Wasting time on worrying about what is going to happen in Phase 2 might take time away from you before you reach it.
Phase 2: surge development - This happens after you've discovered some value for your user. Now the code you write is worth something. You should consider making phase 3's job easier. Proper design patterns etc. But your main concern is replacing the shitty parts from phase 1 with better code (if it's something you touch a lot) and getting it to scale for your now growing user base. You have to make strategic investments here. If you're spending your time making an ugly file that never gets touched better, you're wasting your time. If you're worried about making your code more efficient so you can support more users when another $100/month server would solve the problem, you're probably wasting your time. In phase 2 the company is still mostly worried about revenue, but you have a decent chance of making it into phase 3, so it makes sense to think about it.
Phase 3: maintenance. - In this phase, you're no longer searching for the value for the customer, but rather searching how to shore it up, how to be the best at providing it. Now tech debt is less okay. Crap quality software will lose money, so you should spend time making it bullet proof. Your revenue isn't growing like it used to, so you have to extract as much from it as you can.
> But suddenly because you are an "engineer" this is acceptable?
No, it's acceptable precisely because you aren't an engineer.
We software engineers in the US are not bound by a formal code of ethics like more traditional engineering disciplines. We're not required to invest a certain amount of effort in the security or accessibility or maintainability implications of our work. And, most importantly, we are not legally responsible -- independent of our employers -- for defects in our product that arise from incompetence or otherwise failing to follow best practices.
So, you're wrong and your parent is right. He's not independently responsible for his work, and he has no formal ethical obligations prior to his employment contract.
The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier.
Why are there no other "competitors" in this space? Why do most other languages go with the alternative route of using an event loop or daemonizing your "server" to serve up requests? I can understand why Node.js does it (otherwise the async nature would just be an annoyance for no gain), but why haven't there been any other server-side languages that not only work well like this, but actively target it?
It seems like it would be easier for everyone involved. You wouldn't need much of a GC when the process is killed every time, you don't need to worry about async IO or multi-threading or catching errors or any of the other annoyances that come with most of the traditional "event loop" way of doing things.
>>Why are there no other "competitors" in this space?
There are. Any language that supports either fastcgi, or runs as an apache plugin (or similar) functions in the "each request starts new" space. There's certainly others, but Python and Perl are both good examples.
Starting new with each request does, of course, mean lots of re-work that shouldn't have to be done with each request. It does initially keep complexity down, but at scale, the applications I've worked with have to use a shared cache (like acpu) to avoid that rework and meet performance goals.
I mean more of languages that actually "target" this kind of setup.
I know it can result in a lot of "extra work", but I really feel like most of the pain of that could be abstracted away by the runtime.
Nginx/apache setup a PHP process before the request comes in, so why couldn't you expose that point to your language and let the programming language do work before that point, even "snapshot"ing it to avoid re-doing that work for each request?
It just seems like there are better ways of solving this problem, because an event loop is such a "hammer" solution to the problem.
The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request. Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc. This is usually done on startup or at least cached in memory once it's loaded. This is something that you have to manage more carefully with a PHP app since you can't have anything initialized before a request starts. Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. You can cache that stuff, but it's still overhead that isn't central to handling a request.
There's actually work being done to build PHP frameworks that get around this with ReactPHP, ZeroMQ, Photon, etc. Essentially this is what HHVM does as well, by at least keeping your compiled bytecodes in memory (similar to APC/eAccelarator/ZendOptimizer, etc).
>Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc.
All the magic you ever need can be dynamically created in __get, __set and __call. It works, it works well, and it makes not only reasoning, but also deployment an order of magnitude simpler.
>Code paths, auto-loaders, database connections, config files, etc.
Use a single code path, a single autoloader and a single database connection. Cache the opcodes of stuff you load. Write config files and templates in pure PHP, so they're cached as well. Done.
I've never, ever had problems with bringing PHP page generation time below .1 seconds. Usually it took something like .03 seconds on crappy hardware. And that was without extensive caching of DB results or anything else that's particularly clever.
> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request.
Do you most of those need to happen at all, ever? In my mind, auto-loader is a sign that nobody knows what's being loaded (if they did, they would just require it). Requires should be full pathed (because have you seen what happens when you search the include path). Mysql_pconnect has been doing connection pooling for a long time, mysqli supports it too (so yes, you do need to connect sometimes), anyway, if you're loading a framwork, loading that probably takes longer than connecting to a mysql server in the same colo.
The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request.
Well, it depends on how it's implemented, and how pedantic someone gets about what "shared nothing" means.
There is a long history of unix daemons that initialize, listen(), and then fork off a child process whenever a client connects. The child does all the work and the parent goes back to listening. You can do the "up front" work once and then each child can only modify their copy of the data, preventing it from interfering with the next request.
The real question is why does PHP depend on globals or thread locals for request state at all? PHP's "new process per request" is a solution to a problem that PHP created for itself. In other languages, the request handler receives the request state as an argument, so when the request completes there is no state to reset.
> It seems like it would be easier for everyone involved. You wouldn't need much of a GC when the process is killed every time, you don't need to worry about async IO or multi-threading or catching errors or any of the other annoyances that come with most of the traditional "event loop" way of doing things.
Firing up a new process (or even a new thread) for each request is very expensive--much more so than a generational GC. Async IO also mitigates this (why have 10K parked threads consuming memory all your memory if all of them are stalled, waiting for database)? Services that spawn a thread for each request run into the C10K problem--they can only serve 10K simultaneous clients. Regardless of your concurrency model, you can't ignore errors--you still need to dispatch the right status codes and error information (not to mention logging, etc).
You should check out Go. You write concurrent code and the runtime effectively manages a thread pool under the covers so you get all of the performance benefits of async programming with the developer-friendliness of synchronous programming. In the case of a web app, you just need to write your request handlers--the web server manages the request concurrency for you, and the language's runtime manages the parallelism.
>>PHP's "new process per request" is a solution to a problem that PHP created for itself
True, but I'm not aware of any notable language that did it differently in the mid 1990's when PHP was rolled out. PHP does not spawn a new OS process per request these days. It does spawn a new interpreter, but not a new OS process. Combined with the now bundled opcache, the re-work per request is limited to the developer's own initialization code if they don't choose to use a user-space shared cache.
There are plenty of competitors in this space, they just don't use the CGI model of spawning a new _OS_ process for every request. You have Erlang/Elixir that have their own lightweight processes that don't share memory and have independent GC. And you can build similar systems on Java/Go. The difference is that in those language you have a choice. There are certain types of applications that you just can't reasonably make in PHP.
In fact you can create a "daemonized" webserver in PHP and handle each request in a special handler function. For async case there is ReactPHP (http://reactphp.org/), don't know any product for sync case, but creating one is certainly possible.
And you can also set up Ruby, Python, Rust, Haskell, Java, etc to create a new interpreter/vm/whatever for every request. All of those languages have libraries to support CGI. Using the same OS process but restarting the interpreter/vm will be a bit more complex, but absolutely possible. You can even implement the "every file is an entry point" approach for at least Python and Ruby.
The difference is what is the intended use for each platform. E.g. creating a new OS process, loading the PHP interpreter, bootstrapping Wordpress, getting some data from the DB and rendering a page is possible under 600ms while creating a new OS process, loading the CPython, bootstrapping Django, getting some data from the DB and rendering a page will easily take you 4 seconds. This is because Django developers didn't expect you'll be doing that, so they put a lot of stuff in the initialization step (system checks, creating db connections, setting up logging, ...).
I worked on a large-scale (30m+ users, tons of concurrent sessions and high request rates) site + online service + native client setup in PHP for years.
This was never actually an asset. Startup times were huge, lack of shared state meant extra requests to database servers (and to memcache instances to avoid database round trips) to get the same data per-request. Each request got longer and a given page or api call might issue many duplicate requests in a short period of time.
Plus since PHP doesn't have viable threading or async (definitely didn't at the time) each memcache or sql request had to be synchronous, resulting in even more wasted time. At the very least memcache had good support for batch operations so we could manually batch our queries.
Overall though this is not an asset. It's only the 'best' part of PHP if you don't want to think about writing good software that manages shared state.
To be fair, many applications don't actually benefit from being good code, so PHP is probably a good fit for those.
This is my least favorite part. As soon as your program gets more complicated the amount of repeated parsing, compilation and setup you need to do for every request causes massive speed and structural issues.
You can add a ReactPHP based HTTP server to your app to avoid reinitializing, but you'll have to deal with memory leaks between requests and process management yourself.
The catch is overhead. There are things you need at the start of each request - global configuration, database connections etc - that other systems do once at startup. PHP has to do this every request.
> "reasoning about" (boy do I hate that phrase...)
A bit tangential, but I find myself disliking it too, for no good reason that I can think of.
Perhaps it's something of a crutch in that it's really "I like it more, but 'reason' sounds better" ? Not sure that's quite it, either, as in the above case with a "new everything per request", it's certainly true that it's easier to think about what's happening.
I like the old hacker term for "reasoning about". Grok. It's much easier to grok a program when everything just runs from top to bottom and doesn't jump to a different third party library every 3 lines or have 15 layers of indirection and frameworks.
It's a pretty nuanced phrase and difficult to replace. I might make the case that "easy to reason about" <=> "simple" in the sense that Rich Hickey uses it[1] but that doesn't do anything for the verb itself.
The phrase has a high correlation with subjects that are themselves highly correlated with smug proponents; functional programming is one of the greater ones of these.
Personally I like the phrase. Then again I self-identify as a (non-smug) SmugLispWeenie[2] so of course I like it.
Because it's very wasteful to keep reinterpreting the same page every time, as opposed to just running it in RAM from a warm JIT.
You can get the same reasoning benefits in pretty much any language by just not using any global variables. Yes, you're still running a framework/server with internal state, but with PHP you've got the same "issue" with Apache/Nginx.
> Because it's very wasteful to keep reinterpreting the same page every time, as opposed to just running it in RAM from a warm JIT.
You are running it from RAM. PHP's OPcache, and HHVM, will both compile the code only once (well, HHVM will compile it multiple times due to JIT, but it only touches the disk once) and cache it.
The startup time can be pretty extreme -- although you can mitigate much of this with various caching strategies but the typical PHP request involves reading dozens to maybe hundreds of files from disk, compiling them into byte code, and then executing that byte code, and then deallocating everything.
And even if you cache everything, you still have the code necessary to setup the runtime environment of you application which runs on every request and does the same thing.
But still, I do actually like that model and it does have many advantages for development. But it's really hard to work in PHP, the language, after using something better.
> although you can mitigate much of this with various caching strategies but the typical PHP request involves reading dozens to maybe hundreds of files from disk, compiling them into byte code, and then executing that byte code, and then deallocating everything.
For the conversion to bytecode, that is what apc is for.
I may be waaay off base here, but wouldn't amazon's lambda function architecture sort of mirror the benefits of shared-nothing? It doesn't necessarily work like that under the hood, at least if I remember correctly your lambda function may live on past one request, but you must code as if that were the case
It does, but it comes with deep tie-in to AWS as well.
But also, you don't typically use lambda to serve pages or a full application, more commonly it's used for specific processing tasks, individual endpoints, and generally code that can run standalone.
Starting new, regardless of caching data/bytecode, still means you have to spend time bootstrapping the application.
Other languages, whether directly or indirectly manage cleanup via GC or recycle processes, like UWSGI for Python.
I also don't find any particular benefits over other languages with "reasoning about". As a PHP application grows and a team restructures it into something more mature it ends up looking the same minus the event loop (which just lives somewhere else).
> You wouldn't need much of a GC when the process is killed every time
Yes, you do. You'd be surprised how easily memory balloons out of control unless you regularly run a GC. Log minor collections sometime in Java or JS engines if you don't believe me…
Even worse, if you don't run GC regularly, you will suffer terrible locality as execution continually grows the heap (not to mention the overhead of continually requesting free pages from the OS).
The idea here is that the webserver forks & execs a new process for every request, allocates a bunch of pages, and then runs to completion, at which point the process finishes and the memory is returned to the OS. It's essentially using the OS as an arena, where you can allocate memory at will just by bumping a pointer and then the whole thing is freed at once at the end of the request.
It's not an insane idea - CGI worked exactly like this, as do most command-line shells. And the overhead is often less than most people expect, since most pages are COWed on fork() and the files it touches will likely be in the filesystem cache. Still, I think people found that the overhead from process creation (and in particular, keeping all those processes around & task-switching them while they make DB/network/filesystem calls) was greater than that from GC, and so most frameworks - PHP included, these days! - use a more lightweight mechanism.
Probably because allocating a thread to every request is less efficient then a bunch of event loops with async. Ideally you do both, but a lot of languages choose to make concurrency something done at the process level and are event driven asynchronous web servers which are deployed as multiple processes, which adds a lot of overhead compared to threads. I think Golang has a nice balance with goroutines, as I understand things.
It's interesting that so little know what is Cgi here. It's the Common Gateway Interface and it uses environment variables to communicate to the Cgi scripts and thus the Cgi script can be in whatever language you wish. You don't even need a lib, reading env is enough. Its possible to write your Cgi scripts in assembly.
So this process-per-request thing is not exclusively a Php thing.
I know of CGI scripts (and the newer faster alternatives), I was wondering why more languages don't specifically target that kind of setup, playing to its benefits and trying to minimize the downsides.
About 2-3 orders of magnitude in performance. That’s the catch.
And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons, you use process pools with fastcgi instead of actually creating new processes, etc.
And hacking those things on top of PHP make your program even worse to reason about than just using a daemonized system with actor framework.
Unless you're writing in pure hand-optimized assembly language, 3 orders of magnitude in performance is way more than you could claim. PHP web requests commonly execute in hundreds of ms (of course, here I generalize mercilessly, but that covers most of cases I know of and that's what most sites aim for). So you say your non-PHP requests which would do the same thing would finish in hundreds of microseconds? I have very hard time believing it.
> And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons
You make it sound as if the idea of caching was invented by PHP programmers to address language deficiencies. Nothing can be further from the truth. Everybody uses caches, because it's faster. If you don't use DB cache, there's no way in the universe you can make you app fast under any significant load.
> And hacking those things on top of PHP make your program even worse to reason about
You have very strange view of performance design if you think using caches is "hacking something on top" and has to be avoided.
> than just using a daemonized system with actor framework.
This looks like a complete non-sequitur - you could use actor framework and still use all the things described above, and do it in PHP, and thousands of people do exactly that. On not in PHP, if you'd like - this pattern is completely orthogonal to the language used.
That 2-3 orders of magnitude difference is in an area that runs pretty quickly however.
People go to a lot of trouble to optimize the front end system, but tie it all to the same database that bottlenecks well before the web server. There are certainly times where PHP or CGI aren't fast enough for the job, but I think people tend to unfairly blame them in situations where the underlying problem is more systematic.
And yet it turns out that those 2-3 orders of magnitude don't really matter for the vast majority of products you could develop. Your DB queries no matter the language are several orders of magnitude slower than the interpreting time.
If you need to process thousands of requests per second per thread then don't use PHP, but that's a rare situation. I wouldn't build RTC in PHP. But web or enterprise applications, which are by far more common, don't really suffer that issue.
And pretty much everyone caches database results...
Compared to the other offerings, it's on par or faster (Python and Ruby really have a lot to be desired). You're talking about an actor framework, which is more performant at a cost of using that model and the myriad of issues with managing a more complicated system. The market favors simplicity and less sophisticated developers, in most projects.
> Why are there no other "competitors" in this space?
You can do the exact same thing with any language that supports CGI. You can compile a Go binary, put it on an Apache server and you'll get the "shared nothing lifecycle" just like PHP.
Exactly. The "shared nothing lifecycle" really lets the programmer (knowingly or unknowingly) embrace RESTful design. Too bad the language doesn't have strict typing like Java. Otherwise it'd be even more convenient and safer in my eyes.
I worked in PHP at Box for about 3 years. This article does a great job of reflecting my sentiments on the language. In particular, I'm glad to see that the author recognizes that there are some glaring issues with PHP that aren't tradeoffs in favor of something else - they're just warts.
That said, PHP is really good at what it does - providing a framework and environment for serving web requests efficiently and easily. I find developing in it very fluid once you know how to avoid the warts. A lot of the flak that PHP receives as a language revolves around the fact that it doesn't actively discourage developers from doing bad things, and sometimes the language itself does some crazy stuff (as shown in the article with the divide-by-zero behavior). I think this is a huge shortcoming of the language, especially as code bases and teams grow and your organization needs to depend on the language more and more for safety. That said, I still don't hate working with it. Sometimes I rather enjoy how quickly I can develop in PHP, and how reliable it can be if you know how to operate it.
I think in all, it was a bit of a slog to get to the point where I am with PHP today - to the point where I understand its strengths and flaws, but ultimately I think it does have a place in modern webapp development. I think Hack and HHVM are excellent spiritual successors to what PHP tried to (is trying to?) accomplish, and that they do a great job of hiding or eliminating some of the warts of their parent language.
Kudos to the Slack team for being pragmatic about their approach to the technology, and hey again to all of my former colleagues working there!
I've had to do some PHP work recently, on a fairly old school PHP codebase for a high traffic website, after spending most oy my career working in Java and C# (and I still do most of my work in those languages).
I've read a lot of PHP hate over the years, but I've found working with it in practice to be decidedly...not bad. Perhaps the codebase I inherited is better than most. But I've had to make some fairly major updates, and they've proven to be far less painful than I had expected based on the amount of PHP attacks I'd read online.
Maybe the snobbery toward PHP is a good thing? There are some really big PHP-based communities out there, Wordpress being probably the largest. And in these communities, there appears to be a large demand for paid consulting and plugins. Sure, there's a ton of competition on the low end, but it's an area where a really great developer could stand out from the crowd and do very well financially, especially for more complex consulting and dev work since so many good developers turn their noses up at PHP.
The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C. The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3]). But PHP7 is both fast and productive with many modern first-class features. You can in fact write excellent code without much effort that will handily outperform Python, Ruby and even Node.
The Wordpress codebase [plugin api included], though, is utter garbage.
> The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C.
It was consistent with the thing it inherited most of it's syntax from so that makes it inconsistent?
> The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3])
You shouldn't be judging the way operators work in one language with the way they work in others. Is lisp inherently bad since it's operators are prefix and not infix? No I'd say not, it's just different.
On the other hand, the PHP devs changing the ternary would cause major problems for anything that uses it. The most the PHP devs have done is deprecate methods and add features. That's great. I think that changing something, that has been there since the beginning, to a new behavior is stupid. Much much much worse then having ternary work backwards.
> The Wordpress codebase [plugin api included], though, is utter garbage.
> The devs are ultra-conservative and stubborn to cause BC even at major version bumps
Well, breaking backwards-compatibility comes at a cost. Avoiding another PHP 4/5 or Python 2/3 situation is the goal. It doesn't mean nothing gets changed: PHP 7 has a long list of backwards-compatibility breaks.
> The Wordpress codebase [plugin api included], though, is utter garbage.
I've always heard this and never actually used Wordpress myself. Has anyone ever studied WHY its garbage? and how did it get to that state? is it getting better or are the latest additions and changes still garbage code?
As long as you don't mind working on "boring" projects, there is TONS of small businesses in need of custom work to be done. It's very lucrative, because most people like you said, turn their noses up at the thought of it.
Boring isn't always bad. Last time I tried to create an interesting project, I ended up with a couple hundred MB of node modules before I'd even done much. :)
It is not entirely clear if the author aka Slack chose PHP with these reasons in mind apriori or did they choose PHP first and are now justifying why their choice of PHP is not bad.
I'm going to guess they picked PHP because they knew PHP and not because of the nice reasons mentioned in the article. That is the article should be "why slack is sticking with PHP".
Almost all the major languages are actually (despite lots of HN debate and arguments) fairly good choice for developing not because the major languages are expressive/powerful but because they have very very mature tools (e.g. Java sucks but the JVM and its tools are very mature) and lots of people who know it.
Basically you could write a plethora of articles with "Taking MAJOR_BORING_LANGUAGE Seriously".
For example I'm responsible for choosing Java for my companies startup. Java historically is not a very productive language to pump something out but in recent years it has vastly improved... regardless I chose Java because thats what I knew at the time and I would pick it (or some other JVM language) again. And I could rattle off whole bunch of reasons why the JVM still kicks butt but the reality is I am biased because of my familiarity.
Agreed, and only thing I want to mention is that 'Productive' which people normally think about how fast to develop rather than measure it within the whole system development life cycle – code easy to read and maintain, tools for test/profiling, logging, deploying etc.
Come on, PHP is the 'Justin Bieber' of languages, everyone knows it. Its the most successful and widely used web server language in use and with anything so popular it has a large group of haters.
If anyone wants to come off like a 'serious' programmer, all they need to do is denounce PHP as a horrible aberration, a frankenstein of a language. Most don't even know about the changes in the language over the last decade, they just hate it to stay inline with their peers.
However, those opinions dont line up with the facts. PHP goes beyond semantics of language, it's a complete service for delivering dynamic HTML from the server. Why is it so successful? It is one of the most robust, well supported, battle tested languages to appear in the last 15 years. Its support is guaranteed on any hosting platform or cloud solution available. It has a large array of libraries capable of integrating with most any service whether that be databases, web apis etc. It has the ability to scale for high demand, as demonstrated by the many large corps that use it.
If you want to rip on PHP because it's cool, I think you're simply shooting yourself in the foot and ignoring a tool capable of performing almost any task you would require of it on the server side.
I think there is a needless air of elitism especially here that can only come when people take themselves too seriously, seek validation for their choices, and are always on 'display'. This is also now fuelling a full scale culture of complexity as nobody wants to do things simply lest they be judged as 'unsophisticated' and lose career and other opportunities.
This cannot lead to real conversations or good software. There are far too many naysayers always eager to jump in with their 2 bits of negativity with the same cliched talk points and links most of whom I am sure would never be seen near php and may not even have used it.
The criticism goes silent when HN favourites like Slack show up on discussion. Ignoring the sheer number of high traffic websites and successful startups using PHP is just another way to deny it its due.
Most PHP apps are a breeze to install and use compared to just about any Ruby or Node app. Try installing Discourse to understand just how user hostile it has become. The respect for users and simplicity comes through in PHP. NPM and Ruby with their dependency hell expect a full dev environment even on user machines and nobody thinks this is ridiculous. There is no denying PHP warts but Node, Ruby and Python I think have their fair share of issues.
I really do like Python but for a web project that needs to scale and not get mired in other issues I would choose PHP every single time. For a library or SAAS app maybe, but for an installable app I would never expose users to the Ruby or Node ecosystem.
That example of "Surprise type conversions" is crazy.
Did not know that.
While i do not think PHP is a perfect programing language. There is one think i LOVE about PHP, it is that the PHP "community's" default way of documenting code behavior is to make a small example.
When i read most other languages documentation i read it. Then i need to make a small test to verify that i understood it.
All those tests takes a long time to make and i have to make them over and over again, every time i forget the way a function behaves.
In my experience code examples as documentation are far more common than actual documentation (e.g. guides, user manuals), but perhaps I just haven't worked in a language where the opposite is true.
You can take a look at the node api docs... there are some areas (particularly in crypto), where it's really hard to understand what you need to do, as there are pretty much no examples of actually exercising said code. So you go searching via google, find a similar example, look at the docs again, and hope that you got it right.
It's harder still when you're trying to en/decrypt data from multiple programming languages... Java is particularly painful as well, since a lot of the things that are "standard" are abstracted behind class structures with naming that differs from the standards.
Readit News
I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much.
If you're programming in PHP, you're not running around talking about "convention over configuration" giving talks, or trying to make your code beautiful. It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick. You're failing while the other guy is still updating his gem file. You're advertising while the other guy is trying out some fancy new deploy script. You're incorporating feedback while the other guy is just starting to get to work. When he finally fails, he's used up half his runway, whereas you, the guy who didn't give a fuck about your code has gotten past that first failure, and are finally getting some traction.
Hopefully, the next guy to join the company will clean up your shit. The other guys code may not look like shit, but it doesn't solve any useful problems... so they never got the chance to hire that next guy.
Some companies are succeeding in spite of php. There are many, many users of php, and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum.
It's easy to cherry-pick the winners and miss all of the tremendous losers who picked php and got nothing for it.
Only engineers care about programming languages. Seriously. That's it. No one else cares about them. I work in a large public university alongside a revolving door of student interns who are always 19. In 10+ years of work, I've still yet to meet the person who talked about their favourite website or app, but lamented that it was written in Php or JavaScript or Go or Java. It's only us (the HN'ers) who fret about this.
Don't believe me? Imagine the look on everyone's faces at the tech publishing houses around 2009 when books about Objective-C sold a few hundred copies a year to doing tens of thousands per month when the iPhone rocked the world. This happened without a proper language hot stove on Hacker News, no?
People care about outcomes. People care about products. People care about being dazzled. People care about showing their friends this incredible thing they saw on the web/this new app.
Asking as I've developed in a slew of languages and never found the PHP-bashing credible. Most of the complaints seem to come from Rails people, but there are no shortage of MVC frameworks in PHP, including at least one that is a direct clone of Rails.
The language you use pay second- and third order dividends, but most battles are fought and won on first order.
I'm a C++ developer, have shipped Java and C# and Haskell and Python and a bunch of other code in production. If a friend asks me to spin up a website for him/her quickly, I'd still do it in PHP.
Horses for courses.
Some companies are succeeding in spite of [insert language]. There are many, many users of [insert language], and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum.
It's easy to cherry-pick the winners and miss all of the tremendous losers who picked [insert language] and got nothing for it.
This is exactly right. The right philosophy for PHP is to embrace the garbage. When you're done with a request, and have spit out all the HTML to the client, the server is going to throw everything away. So don't build a beautiful object tree to describe everything, just do the minimum amount of work to take the garbage input and generate the garbage output, and be done. Don't worry too much about your code being beautiful, because it lives in a dump.
This may sound negative, but working in a dump means you don't have to worry about appearances while you do what you came to do. You can always take a shower on the way out :)
PHP didn't succeed because of the "language" part. It succeeded because it was limited and focussed to just being a tool to write small web-apps in a short time.
It did one thing and did it better than anything else of the same era (I built CGI apps in C, Perl and Python before discovering PHP).
It was just files, that you ftp-d in and it just worked.
99% of the friction is in writing the first thousand lines of code and PHP meant that nearly all of those lines was business logic, not unescaping POST data or parsing GET parameters.
PHP doesn't remove your ability to think clearly. It is true that it does not provide helpful additions for algorithmic work, but it does not put challenges in your way when writing web-apps. And yet, it does not force you into too much magic about how it works - just enough abstraction for a messy coder.
All other solutions, java, .net, node, python, Haskell, etc require you to run and maintain your own servers. A minor exception for CGI based solutions but those were all too heavy.
Some good programmers genuinely point out some of the pain points of php, but most programmers paint php as shit just to show off as a good programmer.
I would argue that it still does. It's not a great language, but to just get something working I still can't think of anything better that doesn't require lots of planning or infrastructure
So much time wasted talking about the "right" way to build software, and the best technologies to use, taking positions to bolster your CV or make a name for yourself, and nowhere near enough emphasis on shipping useful, working software.
It drives me slightly nuts. Many people don't realise that technical debt is often a great problem to have because it means you've succeeded. They also want to live in this reality distortion field where they ignore the fact that the code they write today is tomorrow's technical debt because, for reasons I don't fully grasp, they think they're going to do it "right" this time. To quote from Garth Marenghi's Darkplace: "Uh-huh? Bye." In 5 years' time our successors will be wandering around moaning about the crappy code we wrote today, but only if we succeed.
If PHP is the fastest route you know to releasing something worthwhile then more power to you.
(Just to be clear though: I'm not advocating an end justifies means approach to all areas of life.)
V1 is usually shit in any language and if it does what it's supposed to do, it remains shit forever. I've seen shit in C#, Java, and ROR. I've seen stored procedures stringed together inside MSSQL Server vomiting HTML snippets and PS shells giving birth to Excel files to be consumed via network share by some poor soul pressing a button in Excel. I've seen systems written in "enterprise" style, by "enterprise" developers without a single automated test and 20+ levels of abstraction with cross-dependencies running like spider web among 10-some "sub-projects".
I'm not even talking about time-tested shell scripts you can find included by default in your favorite distro or the widely beloved ./configure.
I guess the point is, the language has nothing to do with the attitude of the developer / project manager / product owner. It's easy and convenient to just dump your problems on the tool you're using, but the reality is more deeply rooted in the whole approach to software development (just get shit done), project management (the requirements have just changed, dude!) and the general "i need it done last week" attitude of the product owners.
But sure, let's collectively shit on PHP, just because it's easier. Just like writing shit code is.
I started my career as a PHP developer. Any web project you prototype in C# could be prototyped in PHP in a small fraction of the time.
Finally, good luck with writing a unit test against an API not created by you because, you have to go through deep into the source code just for figuring out what data structure return and give.
However what I find incorrect is the claim that Ruby is a garbage language. Then again, maybe that is best treated as hyperbole, as an exaggerated expression of your dislike for it.
Is that a good idea?
There's a reason that people claim (incorrectly, but still) that somewhere inside of Javascript there's a Scheme dialect, desparately trying to get out. This isn't true, but the proper lambdas and scoping are very scheme-esque.
Theres a lot of raise ArgumentError.new unless foo.kind_of? Bar
Going on in my code these days.
I think JS is better than PHP, at least when it comes to: 1.) consistency of std lib and 2.) type casting. There are many surprises with PHP's type casting. See /r/lolphp sorted from top all-time: https://www.reddit.com/r/lolphp/top/?sort=top&t=all
Whatever I would say about PHP - how good or bad is - I am almost forced to use it - In central/eastern europe almost any company uses it to develop web-backend... but I really would love to jump to Node/Go/Golang-based development team (maybe even remotely).
[1]: http://laravel-recipes.com/recipes/60/optimizing-the-framewo...
- You sit in a dining table with 50 different utensils. White wine glass, red wine glass, water cup, salad fork, dinner fork, dinner knife, teaspoon, soup spoon, bread plate with knife...
- When the food is served, you take the food, drop it on the floor, eat it with your face (not even using your hands).
"get shit done"... use spoon as a knife and knife as a fork, or try to sniff your food through your nose instead of eating it.
If PHP gets you to first base (MVP) in 10% of the time than NiceLangX then you get 10 X more chances to throw shit at the wall and see what sticks.
It is probably ok if you work for a startup that does not survive long enough for the quality of your code to matter anyway. But in a regular company, your attitude creates a time bomb when eventually any apparently simple change may destroy the codebase (and at best, it just takes too long to make any change).
Bad code isn't Technical Debt, it's an unhedged Call Option http://higherorderlogic.com/2010/07/bad-code-isnt-technical-...
I do my part today by acknowledging all of my code is bad, therefore I don't invest a lot of time or ego in it. I try to make it in reasonably sized pieces so it's easier to rip out later (this may make it slightly less bad). If someone comes and tells me my code is terrible, I say yes it is, you might want to consider these things when you replace it.
EDIT: my opinions on this would change if I were shipping code to run on other people's machines: it's generally easy and quick to fix my code on machines I run, but updating code on other people may never update, you need to try harder to get it right the first time.
A couple of months back there was this php sucks article about being looked down upon because you do php for a living. Php is the language people bitch about to feel better about themselves. Even within the php community symfony developers don't take drupal developers seriously. It's sad really and even I'm guilty of doing that. A little more respect for your fellow developers is all we need. It's like judging a book by it's cover. How would you feel if <insert your fav lang> was treated that way.
Php has a lot going for it. The community is very active and passionate, new things come out at a rate you can keep up with. You can easily get passionate about it if you engage in it. A lot of interesting projects are (being) build with it and it is obvious that php won't disappear anytime soon.
If you have to work with php and bitch about it, make the effort and solve the problem you have with it. Contribute back to the community and experience the gratitude. You'll enjoy your work more.
So there are php people that care and they try to make the best of it. I don't think they consider it to be a garbage language. They are the ones that made php what it is today which is something totally different compared to what it was years ago.
But business success is largely orthogonal to language choice. I.e. when you buy a paid Github plan do you check what language they write the site in?
Of course a strongly typed languages should tend to have less bugs and that will save money. But saving money is only useful for those with revenue to being with.
But I see what you're getting at... if you need to whip up something quick, don't start experimenting with the "flavor of the day" language or library.
The one thing you want to avoid are communities that argue about "the best" way to do things. Even then, you can use the fruits of their labors, as long as they're willing to package it up in something that gets out of your way and lets you get work done. You just need to take the language but not the community.
I do care about my code though. I think you can write niceish code, even with a shitty language.
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
That said, all environments will be one of three:
1 Have warts. 2 Not be used. 3 Be in denial and claim to be perfect.
The GP had a point, perfection is the enemy of good. Something delivered is better than nothing.
Deleted Comment
> They just don't care.
> It's a garbage language.
I think this overly dismissive/elitist approach is part of the reason why alternatives failed. Couple that with the ridiculous claim that a developers' time does not matter.
Almost any big app you can point to that is built in PHP today was bootstrapped in this environment.
I did a lot of PHP from the late '90s up until 2008. Maybe things have changed in the intervening eight years, but I cant say I miss it.
Now I don't fret as much about unsexy tech. I do still advocate for new things when they make the team more productive, but I hope I never have to work at a place again where the latest and greatest stuff is used and people get nothing done.
My perception of the Clojure crowd is the exact opposite. They seem to be a bit too in love with the process and craft and not enough with the end results. That being said, I'd much rather code Clojure as a day job (I promise to be market focused!) than PHP. Right now I am almost all Python. There are definitely a lot of Python folks who are too much enamored with the craft, but the crowd is so big there's plenty of room for the GTD folks.
Painful to read. I've struggled with this my whole career.
Reminds me of Alistair Cockburn's seminal essay about methodologies.
Characterizing people as non-linear, first-order components in software development
http://bit.ly/1eDUNlE
Money quote:
"Problem 1. The people on the projects were not interested in learning our system.
Problem 2. They were successfully able to ignore us, and were still delivering software, anyway."
I'm overwhelmed by how rich of a statement that is.
If you consider Wordpress a success then yes PHP is successful. The thing is, a CMS isn't an interesting project to work on.
Deleted Comment
Deleted Comment
I'm going to frame these words and hang them on my desk.
Dead Comment
If you want fast, build a static site. If you're iterating on your builds and doing something non-trivial, pick your tools carefully but don't be afraid to try new things.
As of PHP7... it actually is quicker than other languages in it's domain.
Is that acting in the best interest of your employer? or ripping your employer off? I think more like the latter.
Imagine if other professions behaved like this, like finance or legal people. But suddenly because you are an "engineer" this is acceptable? If I was your boss I would fire you immediately.
The world of difference between balancing trade-offs in technical debt, tradeoffs in long-term/short-term goals, and deliberatively sabotaging the company by leaving technical debt for other people to clean.
You are a liability to the company and its culture. And you want people like you and your language to be taken seriously? that's why nobody wants to work with people like you.
There are 3 phases:
Phase 1: Initial development - Your goal here is to find the value to your user. Any code you write here should be considered disposable. If it's not valuable to your customer, it's not worth building right... if it takes time before you know it's valuable to your customer, it's not worth your time. If you're writing it to support millions of users, and you only have 100, you're wasting your time. In phase 1 you're concerned about creating revenue, and nothing else matters. Wasting time on worrying about what is going to happen in Phase 2 might take time away from you before you reach it.
Phase 2: surge development - This happens after you've discovered some value for your user. Now the code you write is worth something. You should consider making phase 3's job easier. Proper design patterns etc. But your main concern is replacing the shitty parts from phase 1 with better code (if it's something you touch a lot) and getting it to scale for your now growing user base. You have to make strategic investments here. If you're spending your time making an ugly file that never gets touched better, you're wasting your time. If you're worried about making your code more efficient so you can support more users when another $100/month server would solve the problem, you're probably wasting your time. In phase 2 the company is still mostly worried about revenue, but you have a decent chance of making it into phase 3, so it makes sense to think about it.
Phase 3: maintenance. - In this phase, you're no longer searching for the value for the customer, but rather searching how to shore it up, how to be the best at providing it. Now tech debt is less okay. Crap quality software will lose money, so you should spend time making it bullet proof. Your revenue isn't growing like it used to, so you have to extract as much from it as you can.
No, it's acceptable precisely because you aren't an engineer.
We software engineers in the US are not bound by a formal code of ethics like more traditional engineering disciplines. We're not required to invest a certain amount of effort in the security or accessibility or maintainability implications of our work. And, most importantly, we are not legally responsible -- independent of our employers -- for defects in our product that arise from incompetence or otherwise failing to follow best practices.
So, you're wrong and your parent is right. He's not independently responsible for his work, and he has no formal ethical obligations prior to his employment contract.
Why are there no other "competitors" in this space? Why do most other languages go with the alternative route of using an event loop or daemonizing your "server" to serve up requests? I can understand why Node.js does it (otherwise the async nature would just be an annoyance for no gain), but why haven't there been any other server-side languages that not only work well like this, but actively target it?
It seems like it would be easier for everyone involved. You wouldn't need much of a GC when the process is killed every time, you don't need to worry about async IO or multi-threading or catching errors or any of the other annoyances that come with most of the traditional "event loop" way of doing things.
So what's the catch?
There are. Any language that supports either fastcgi, or runs as an apache plugin (or similar) functions in the "each request starts new" space. There's certainly others, but Python and Perl are both good examples.
Starting new with each request does, of course, mean lots of re-work that shouldn't have to be done with each request. It does initially keep complexity down, but at scale, the applications I've worked with have to use a shared cache (like acpu) to avoid that rework and meet performance goals.
I know it can result in a lot of "extra work", but I really feel like most of the pain of that could be abstracted away by the runtime.
Nginx/apache setup a PHP process before the request comes in, so why couldn't you expose that point to your language and let the programming language do work before that point, even "snapshot"ing it to avoid re-doing that work for each request?
It just seems like there are better ways of solving this problem, because an event loop is such a "hammer" solution to the problem.
There's actually work being done to build PHP frameworks that get around this with ReactPHP, ZeroMQ, Photon, etc. Essentially this is what HHVM does as well, by at least keeping your compiled bytecodes in memory (similar to APC/eAccelarator/ZendOptimizer, etc).
See: http://reactphp.orghttp://www.photon-project.comhttps://gnugat.github.io/2016/04/13/super-speed-sf-react-php...
Even the idea of an alternative runtime for PHP (ala HHVM) is nothing new: http://quercus.caucho.com
So? If it takes < 1ms, what's the harm? And opcode cache comes out of the box and most PHP DB drivers can use connection pooling.
We serve most of our requests in < 10ms, and we're not even on PHP7 yet.
All the magic you ever need can be dynamically created in __get, __set and __call. It works, it works well, and it makes not only reasoning, but also deployment an order of magnitude simpler.
>Code paths, auto-loaders, database connections, config files, etc.
Use a single code path, a single autoloader and a single database connection. Cache the opcodes of stuff you load. Write config files and templates in pure PHP, so they're cached as well. Done.
I've never, ever had problems with bringing PHP page generation time below .1 seconds. Usually it took something like .03 seconds on crappy hardware. And that was without extensive caching of DB results or anything else that's particularly clever.
Do you most of those need to happen at all, ever? In my mind, auto-loader is a sign that nobody knows what's being loaded (if they did, they would just require it). Requires should be full pathed (because have you seen what happens when you search the include path). Mysql_pconnect has been doing connection pooling for a long time, mysqli supports it too (so yes, you do need to connect sometimes), anyway, if you're loading a framwork, loading that probably takes longer than connecting to a mysql server in the same colo.
Well, it depends on how it's implemented, and how pedantic someone gets about what "shared nothing" means.
There is a long history of unix daemons that initialize, listen(), and then fork off a child process whenever a client connects. The child does all the work and the parent goes back to listening. You can do the "up front" work once and then each child can only modify their copy of the data, preventing it from interfering with the next request.
> It seems like it would be easier for everyone involved. You wouldn't need much of a GC when the process is killed every time, you don't need to worry about async IO or multi-threading or catching errors or any of the other annoyances that come with most of the traditional "event loop" way of doing things.
Firing up a new process (or even a new thread) for each request is very expensive--much more so than a generational GC. Async IO also mitigates this (why have 10K parked threads consuming memory all your memory if all of them are stalled, waiting for database)? Services that spawn a thread for each request run into the C10K problem--they can only serve 10K simultaneous clients. Regardless of your concurrency model, you can't ignore errors--you still need to dispatch the right status codes and error information (not to mention logging, etc).
You should check out Go. You write concurrent code and the runtime effectively manages a thread pool under the covers so you get all of the performance benefits of async programming with the developer-friendliness of synchronous programming. In the case of a web app, you just need to write your request handlers--the web server manages the request concurrency for you, and the language's runtime manages the parallelism.
True, but I'm not aware of any notable language that did it differently in the mid 1990's when PHP was rolled out. PHP does not spawn a new OS process per request these days. It does spawn a new interpreter, but not a new OS process. Combined with the now bundled opcache, the re-work per request is limited to the developer's own initialization code if they don't choose to use a user-space shared cache.
Which isn't what PHP does, fwiw.
And you can also set up Ruby, Python, Rust, Haskell, Java, etc to create a new interpreter/vm/whatever for every request. All of those languages have libraries to support CGI. Using the same OS process but restarting the interpreter/vm will be a bit more complex, but absolutely possible. You can even implement the "every file is an entry point" approach for at least Python and Ruby.
The difference is what is the intended use for each platform. E.g. creating a new OS process, loading the PHP interpreter, bootstrapping Wordpress, getting some data from the DB and rendering a page is possible under 600ms while creating a new OS process, loading the CPython, bootstrapping Django, getting some data from the DB and rendering a page will easily take you 4 seconds. This is because Django developers didn't expect you'll be doing that, so they put a lot of stuff in the initialization step (system checks, creating db connections, setting up logging, ...).
This was never actually an asset. Startup times were huge, lack of shared state meant extra requests to database servers (and to memcache instances to avoid database round trips) to get the same data per-request. Each request got longer and a given page or api call might issue many duplicate requests in a short period of time.
Plus since PHP doesn't have viable threading or async (definitely didn't at the time) each memcache or sql request had to be synchronous, resulting in even more wasted time. At the very least memcache had good support for batch operations so we could manually batch our queries.
Overall though this is not an asset. It's only the 'best' part of PHP if you don't want to think about writing good software that manages shared state.
To be fair, many applications don't actually benefit from being good code, so PHP is probably a good fit for those.
Here is an example in C: https://www.cs.tut.fi/~jkorpela/forms/cgic.html
Php was born out of trying to reduce a lot of that cruft and blending code and html output easily. And that's what initially made it a winner.
Which should be near 0 if you can be bothered to enable OPcache in php.ini. Not only parsing/disk reading but also bytecode generation are bypassed.
A bit tangential, but I find myself disliking it too, for no good reason that I can think of.
Perhaps it's something of a crutch in that it's really "I like it more, but 'reason' sounds better" ? Not sure that's quite it, either, as in the above case with a "new everything per request", it's certainly true that it's easier to think about what's happening.
The phrase has a high correlation with subjects that are themselves highly correlated with smug proponents; functional programming is one of the greater ones of these.
Personally I like the phrase. Then again I self-identify as a (non-smug) SmugLispWeenie[2] so of course I like it.
[1] https://www.infoq.com/presentations/Simple-Made-Easy [2] http://web.archive.org/web/20160709054130/http://c2.com/cgi/...
You can get the same reasoning benefits in pretty much any language by just not using any global variables. Yes, you're still running a framework/server with internal state, but with PHP you've got the same "issue" with Apache/Nginx.
You are running it from RAM. PHP's OPcache, and HHVM, will both compile the code only once (well, HHVM will compile it multiple times due to JIT, but it only touches the disk once) and cache it.
Define "very". Because for me it's more like "a few hundred microseconds per request".
Deleted Comment
And even if you cache everything, you still have the code necessary to setup the runtime environment of you application which runs on every request and does the same thing.
But still, I do actually like that model and it does have many advantages for development. But it's really hard to work in PHP, the language, after using something better.
For the conversion to bytecode, that is what apc is for.
But also, you don't typically use lambda to serve pages or a full application, more commonly it's used for specific processing tasks, individual endpoints, and generally code that can run standalone.
Other languages, whether directly or indirectly manage cleanup via GC or recycle processes, like UWSGI for Python.
I also don't find any particular benefits over other languages with "reasoning about". As a PHP application grows and a team restructures it into something more mature it ends up looking the same minus the event loop (which just lives somewhere else).
Yes, you do. You'd be surprised how easily memory balloons out of control unless you regularly run a GC. Log minor collections sometime in Java or JS engines if you don't believe me…
Even worse, if you don't run GC regularly, you will suffer terrible locality as execution continually grows the heap (not to mention the overhead of continually requesting free pages from the OS).
It's not an insane idea - CGI worked exactly like this, as do most command-line shells. And the overhead is often less than most people expect, since most pages are COWed on fork() and the files it touches will likely be in the filesystem cache. Still, I think people found that the overhead from process creation (and in particular, keeping all those processes around & task-switching them while they make DB/network/filesystem calls) was greater than that from GC, and so most frameworks - PHP included, these days! - use a more lightweight mechanism.
Not that I feel cgi is the most efficient way to handle requests... but not needing the complexity of GC could be one advantage of that approach...
Any recommended places to start with?
So this process-per-request thing is not exclusively a Php thing.
About 2-3 orders of magnitude in performance. That’s the catch.
And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons, you use process pools with fastcgi instead of actually creating new processes, etc.
And hacking those things on top of PHP make your program even worse to reason about than just using a daemonized system with actor framework.
> And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons
You make it sound as if the idea of caching was invented by PHP programmers to address language deficiencies. Nothing can be further from the truth. Everybody uses caches, because it's faster. If you don't use DB cache, there's no way in the universe you can make you app fast under any significant load.
> And hacking those things on top of PHP make your program even worse to reason about
You have very strange view of performance design if you think using caches is "hacking something on top" and has to be avoided.
> than just using a daemonized system with actor framework.
This looks like a complete non-sequitur - you could use actor framework and still use all the things described above, and do it in PHP, and thousands of people do exactly that. On not in PHP, if you'd like - this pattern is completely orthogonal to the language used.
People go to a lot of trouble to optimize the front end system, but tie it all to the same database that bottlenecks well before the web server. There are certainly times where PHP or CGI aren't fast enough for the job, but I think people tend to unfairly blame them in situations where the underlying problem is more systematic.
If you need to process thousands of requests per second per thread then don't use PHP, but that's a rare situation. I wouldn't build RTC in PHP. But web or enterprise applications, which are by far more common, don't really suffer that issue.
And pretty much everyone caches database results...
Compared to the other offerings, it's on par or faster (Python and Ruby really have a lot to be desired). You're talking about an actor framework, which is more performant at a cost of using that model and the myriad of issues with managing a more complicated system. The market favors simplicity and less sophisticated developers, in most projects.
A rewrite I worked on, from PHP to C++, had an improvement of 20 times better performance.
That's only one (1) order of magnitude.
Deleted Comment
The catch are couple.
First Concurrency is _hard_ and relying on the OS scheduler would have been really har don ressource until recently, which is why nearly noone did it.
That used ot be a wart of php, only hidden by Moore's Law and recent work on OS schedulers.
But yeah. Erlang do this since the 80s
Actually I have never seen that this was a problem in practice with the application server model. I therefore don't think this is a relevant argument.
You can do the exact same thing with any language that supports CGI. You can compile a Go binary, put it on an Apache server and you'll get the "shared nothing lifecycle" just like PHP.
Isn't there a downside to that? If you want to do multi-threading, you can't just do `ThreadPool.StartNew(() => doSomething())`. You're SOL.
It’s really interesting, last time I worked with PHP was a few years ago, then recently I wrote something in PHP 7, and it is a lot safer.
(But still no compile time type checking because there is no compile time).
That said, PHP is really good at what it does - providing a framework and environment for serving web requests efficiently and easily. I find developing in it very fluid once you know how to avoid the warts. A lot of the flak that PHP receives as a language revolves around the fact that it doesn't actively discourage developers from doing bad things, and sometimes the language itself does some crazy stuff (as shown in the article with the divide-by-zero behavior). I think this is a huge shortcoming of the language, especially as code bases and teams grow and your organization needs to depend on the language more and more for safety. That said, I still don't hate working with it. Sometimes I rather enjoy how quickly I can develop in PHP, and how reliable it can be if you know how to operate it.
I think in all, it was a bit of a slog to get to the point where I am with PHP today - to the point where I understand its strengths and flaws, but ultimately I think it does have a place in modern webapp development. I think Hack and HHVM are excellent spiritual successors to what PHP tried to (is trying to?) accomplish, and that they do a great job of hiding or eliminating some of the warts of their parent language.
Kudos to the Slack team for being pragmatic about their approach to the technology, and hey again to all of my former colleagues working there!
I've read a lot of PHP hate over the years, but I've found working with it in practice to be decidedly...not bad. Perhaps the codebase I inherited is better than most. But I've had to make some fairly major updates, and they've proven to be far less painful than I had expected based on the amount of PHP attacks I'd read online.
Maybe the snobbery toward PHP is a good thing? There are some really big PHP-based communities out there, Wordpress being probably the largest. And in these communities, there appears to be a large demand for paid consulting and plugins. Sure, there's a ton of competition on the low end, but it's an area where a really great developer could stand out from the crowd and do very well financially, especially for more complex consulting and dev work since so many good developers turn their noses up at PHP.
The Wordpress codebase [plugin api included], though, is utter garbage.
[1] http://www.phpsadness.com/
[2] http://php.net/manual/en/language.expressions.php
[3] https://www.mail-archive.com/internals@lists.php.net/msg7196... (yes, i asked for this in 2014)
It was consistent with the thing it inherited most of it's syntax from so that makes it inconsistent?
> The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3])
You shouldn't be judging the way operators work in one language with the way they work in others. Is lisp inherently bad since it's operators are prefix and not infix? No I'd say not, it's just different.
On the other hand, the PHP devs changing the ternary would cause major problems for anything that uses it. The most the PHP devs have done is deprecate methods and add features. That's great. I think that changing something, that has been there since the beginning, to a new behavior is stupid. Much much much worse then having ternary work backwards.
> The Wordpress codebase [plugin api included], though, is utter garbage.
Yes, yes it is. That's not the language's fault.
Well, breaking backwards-compatibility comes at a cost. Avoiding another PHP 4/5 or Python 2/3 situation is the goal. It doesn't mean nothing gets changed: PHP 7 has a long list of backwards-compatibility breaks.
I've always heard this and never actually used Wordpress myself. Has anyone ever studied WHY its garbage? and how did it get to that state? is it getting better or are the latest additions and changes still garbage code?
I'm going to guess they picked PHP because they knew PHP and not because of the nice reasons mentioned in the article. That is the article should be "why slack is sticking with PHP".
Almost all the major languages are actually (despite lots of HN debate and arguments) fairly good choice for developing not because the major languages are expressive/powerful but because they have very very mature tools (e.g. Java sucks but the JVM and its tools are very mature) and lots of people who know it.
Basically you could write a plethora of articles with "Taking MAJOR_BORING_LANGUAGE Seriously".
For example I'm responsible for choosing Java for my companies startup. Java historically is not a very productive language to pump something out but in recent years it has vastly improved... regardless I chose Java because thats what I knew at the time and I would pick it (or some other JVM language) again. And I could rattle off whole bunch of reasons why the JVM still kicks butt but the reality is I am biased because of my familiarity.
If anyone wants to come off like a 'serious' programmer, all they need to do is denounce PHP as a horrible aberration, a frankenstein of a language. Most don't even know about the changes in the language over the last decade, they just hate it to stay inline with their peers.
However, those opinions dont line up with the facts. PHP goes beyond semantics of language, it's a complete service for delivering dynamic HTML from the server. Why is it so successful? It is one of the most robust, well supported, battle tested languages to appear in the last 15 years. Its support is guaranteed on any hosting platform or cloud solution available. It has a large array of libraries capable of integrating with most any service whether that be databases, web apis etc. It has the ability to scale for high demand, as demonstrated by the many large corps that use it.
If you want to rip on PHP because it's cool, I think you're simply shooting yourself in the foot and ignoring a tool capable of performing almost any task you would require of it on the server side.
This cannot lead to real conversations or good software. There are far too many naysayers always eager to jump in with their 2 bits of negativity with the same cliched talk points and links most of whom I am sure would never be seen near php and may not even have used it.
The criticism goes silent when HN favourites like Slack show up on discussion. Ignoring the sheer number of high traffic websites and successful startups using PHP is just another way to deny it its due.
Most PHP apps are a breeze to install and use compared to just about any Ruby or Node app. Try installing Discourse to understand just how user hostile it has become. The respect for users and simplicity comes through in PHP. NPM and Ruby with their dependency hell expect a full dev environment even on user machines and nobody thinks this is ridiculous. There is no denying PHP warts but Node, Ruby and Python I think have their fair share of issues.
I really do like Python but for a web project that needs to scale and not get mired in other issues I would choose PHP every single time. For a library or SAAS app maybe, but for an installable app I would never expose users to the Ruby or Node ecosystem.
While i do not think PHP is a perfect programing language. There is one think i LOVE about PHP, it is that the PHP "community's" default way of documenting code behavior is to make a small example.
When i read most other languages documentation i read it. Then i need to make a small test to verify that i understood it.
All those tests takes a long time to make and i have to make them over and over again, every time i forget the way a function behaves.
It's harder still when you're trying to en/decrypt data from multiple programming languages... Java is particularly painful as well, since a lot of the things that are "standard" are abstracted behind class structures with naming that differs from the standards.