I've always liked PHP. You wouldn't pick it for your job interview's coding test if you had a choice (Python all the way there), but it's so intertwined with the internet and what we've learned about programming over the years. First mover advantage kind of deal.
And I've never had to deal with ESM/CJS/AMD whatever module nonsense with PHP. No transpiling anything, just edit and refresh. And so many useful functions out of the box (array_column anyone?).
I think its bad rap comes from its ubiquity. Pretty much any existing website I've had to work on has been a putrid mess. That's just the way codebases go unless you're a SaaS with a CTO who's hell bent on preventing that.
And since most of these putrid messes have been based on PHP, due to it's age and ubiquity, people blame it, due to observation bias.
> You wouldn't pick it for your job interview's coding test if you had a choice (Python all the way there),
I do actually pick it for several reasons.
1. I want to know if the environment I am going into is pragmatic about languages. If you are going to refuse to continue working with me over something so minor as PHP then we aren't a culture fit.
2. I want to showcase my best. I know this language in and out. It's the first language I learned and I have the greatest ease of building algorithms with it. I've had interviews where I was asked to do something with PHP that PHP did not support and I found ways to make it work.
3. In some ways I love the conversation that comes with positive interviews when using it. Oftentimes the interviewer isn't very familiar and it sparks discussion on the languages benefits and drawbacks further showcasing my skillset.
Sure as we progress along in the interview process I will switch to whatever language the company uses primarily but if I get a choice I always choose PHP.
Your comment articulates my thoughts on PHP very succinctly. Especially the culture fit bit. PHP is so insanely pragmatic that if someone looks down on it due to false preconceived notions then they're not the kind of person I can probably work happily with anyway.
PHP has its fair share of snobbery as well. Non-framework devs look down on Symfony, who in turn look down on Laravel devs, and everybody looks down on WordPress devs.
I started out as a symfony snob. Got sick of writing java in PHP so I picked up laravel. Got sick of having to modify my code every time Taylor huffed some new shit so I started building things using WordPress.
It's so refreshing knowing that my websites auto update themselves and I never have to update them unless there is a legitimate reason to do so.
Backwards compatibility is the ONLY thing I care about in a framework. Life's too short to babysit some frameworks ideas of how my code should work ten years after building the damn thing.
Yea, don't debate that. I just personally have no tolerance for the behaviour of these framework developers and the level of work they impose on their users.
For a business that has engineers to manage this day to day it's less of an issue. For building things you want to live online untouched for a decade it's just not an option.
Laravel is nice to build stuff fast in one particular way. It's awful to maintain and heaven forbid you have a different idea about how things should be done.
Every language does, I think it comes with the territory of any domain where fine details matter. The trick is to cultivate your own opinions and approach to excellence, but recognize there are a lot of different things to optimize for, and no one likes a comic-book guy attitude.
Maybe because they have been actively sabotaging progress and dissing those pushing for progress? gophp5 in 2008 pushed everyone but Wordpress off PHP4 and some Wordpress core committers as recently as 2017 have called gophp5 an "abysmal failure" despite it was anything but.
Not to nitpick but choosing a programming language isn't a minor decision nor is switching programming style, e.g. OOB vs FP. Of course I agree with the intend and I too want to work in pragmatic and explorative programming environments trying out different programming languages and styles depending on the project.
>Not to nitpick but choosing a programming language isn't a minor decision
In the grand scheme of things, talking solely about software projects not life in general, it kind of is.
Most modern languages, are interchangeable, and projects of most kinds have been done with all of them succesfully.
As long as the programmers for the chosen language are available, and the libs you want are there, for startups doing some web backend for example, it doesn't really matter if it's Python, Ruby, JS/Node, PHP, C#, Go, Java, CL, Kotlin, Clojure, and so on.
I don't think "interchangeable" is the right word here. In some cases, perhaps, but different languages have different idioms and, since you have Clojure on there, different paradigms. If the individual coming into the new language is diligent about learning how to properly work in it, then all is well. If they decide to try and force what they already know into the new language, that is problem. I've experienced the latter far more often than the former. If you're working for a feature factory, though, I guess it doesn't matter.
> "I don't think Typescript is needed most of the time
This is a terrible example, typescript (especially in 2023) is basically free with most setups (including vanilla) and easy to ignore for velocity then optionally enforce typechecking later.
A much better hill to die on would be large frameworks/tooling like react/angular/webpack.
Bad rap comes from the inconsistency of the early APIs. The ability to interleave code and HTML was also tacky and never taken seriously but I think touted highly by some as a killer feature. The language is very unplanned, go look at an equality chart for PHP, it makes JavaScript blush as well.
"The ability to interleave code and HTML was also tacky and never taken seriously" - That was the whole point of it! The day I found PHP and could leave behind the cgi-bin and SSI it became my favourite thing - and has paid me well for the last 20+ years :)
Putting HTML inside of scripted code blocks was legendary back in the day and every web-oriented language did it. I guess people have already forgotten about ASP and ColdFusion. Being able to for each an array into table rows? Game changing.
I have been coding in coldfusion (openbluedragon) on 2012. Still lurks in my dreams. I refactored to components (objects) some functionalities as a POC, it did not fit well with the main programmer.
Yeah, a big problem with the traditional PHP-in-HTML approach to generating web sites is that it's one of the areas where PHP hasn't dramatically improved since the early days. Later templating engines learned from the problems people encountered with PHP and were built to be aware of the output format, and PHP never did that. A lot of work was put into writing templating engines in PHP that in retrospect really should have instead been a language mode for PHP itself.
We would have seen dramatically fewer bugs and injection attacks over the years if PHP had made <input value="<?=$value?>"> a perfectly safe and normal thing to write back in 2005.
There are actually shockingly few context-sensitive templating languages for php and those that exist don't seem that popular (Latte is the main one I'm aware of). Most of them are more of the giant string concatenation type, maybe with escape by default semantics (e.g. Smarty, Mustache).
> make non-strict comparisons more useful and less error prone, by using a number comparison only if the string is actually numeric. Otherwise the number is converted into a string, and a string comparison is performed.
I too find this hilarious. Not because I want to defend PHP, but moreso that I personally sort of despise react and it's whole ecosystem. I've never liked writing code less than when dealing with a spaghetti monster react app.
JSX and PHP are actually seriously different. When you break out of PHP, you're just outputting text to standard output. When you're using JSX syntax, you're constructing Javascript objects that can be manipulated using standard javascript techniques. Anyone who believes they're comparable seriously doesn't understand the task that is before them.
My reading of this thread is that people are comparing JSX as a templating language to PHP as a templating language, splicing PHP <? ... ?> into HTML like how we have { ... } in JSX. At the end of the day React lets you write a function that returns HTML just like a PHP file.
The bad original library, the original lack of features that help against bad coding practices and the fact that it is so accessible to beginner programmers that you’ll find a lot of beginner code.
The ability to mix html and code means it’s extremely easy to get started which is the big strength.
PHP is akin to, I don't know, the Subway (fast food restaurant chain) of programming languages?
You don't hear too much about it. You almost never notice it unless you're actually looking for it, unlike McDonald's with its ostentatious golden arches.
It's popularity is waning. But it's still everywhere. [0] There are a hundred other sandwich chains that have tried to do it better but none have managed the ubiquity of Subway.
People like to look down on it and espouse the alternatives, but when it comes down to it fast food can only ever be so good.
I don't think that applies though. If anything, laravel is pushing PHP into another "golden age" not seen since code igniter 2, with again a framework that does things not quite how they should be under the hood, but definitely how people need them to be to be fast and efficient, except this time backed up by a proper package management system, a much better and stronger language and an ecosystem based on reusable modules.
Does it have the favor of the modern hype or new language seeker or anything like that ? No, absolutely not, but when has PHP ever had that ?
With this analogy python would be the Ikea. You can go for the fast food (site scripting) or you can get really invested and build out your ML modules with it at scale ( remodeling a decking out your kitchen)
> I guess that means that JavaScript is McDonald's?
My first reaction to this was that it's actually very accurate insofar that I genuinely wonder how one can like either of these and why they're so popular. At least JavaScript has the obvious excuse that it's the only thing that runs in a browser, so it's still more logical than the popularity of McDonald's.
I haven't used it for a long while, but I did a LOT of PHP5, several years. In my opinion PHP4 was horrific (from a language/standard library perspective, most languages you can get what you want done regardless of that), a lot of it carried over into PHP5 despite being a lot better (e.g. see phpsadness). Then the fiasco that was 6/7/whatever made it really hard to have confidence in the future of PHP.
No idea how recent PHP is. It's hard to escape those opinions that formed fairly widely in the industry is, though.
I've gotten a lot of value by being able to go to a library in my vendor folder, and add some var_dumps in there to figure out where my code is going wrong. The way the dependencies works is magnificent.
And I've never had to deal with ESM/CJS/AMD whatever module nonsense with PHP. No transpiling anything, just edit and refresh. And so many useful functions out of the box (array_column anyone?).
I think its bad rap comes from its ubiquity. Pretty much any existing website I've had to work on has been a putrid mess. That's just the way codebases go unless you're a SaaS with a CTO who's hell bent on preventing that.
And since most of these putrid messes have been based on PHP, due to it's age and ubiquity, people blame it, due to observation bias.