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

It's also the thing I'm best at!

And they are humble. They know their state, the flaws in their language and the long problematic history they have.

They cherish their languages but are not fanatics.

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.

Symfony and Laravel have their proper usages.

I used to be Symfony snob too but tried Laravel and I definitely see its strengths.

Laravel was not the right choice with our homegrown, non-framework app, with an existing schema.

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.

> and everybody looks down on WordPress devs.

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.

I would look down on any group not using a framework, or rolling their own.

That's a good point, I imagine doing that would screen out companies run by language snobs.

My go to for this is to say "I don't think Typescript is needed most of the time". The snobs look at you like you just farted in their face.

But having done some coding interviews where time and space complexity were a factor, I found it easier to succeed with Python.

> "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.

Exactly. If the interviewer responds like that, they've told me the company culture, and I know to stay away.

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.

[delayed]

I disagree. There will be lots of considerations like ecosystems, long term support, ease to find developers, prior experience, etc…

Probably missed the "As long as the programmers for the chosen language are available, and the libs you want are there" part.

Working with Clojure is a world apart compared with any of the others listed.

In the end of the day, not that different.

Besides, I included CL there.

If you worked long enough, language or code style are beginning to become almost completely irrelevant

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

And yet people would take a bullet for React and the JSX templates.

Funny how "server side rendering" became a hot new thing too.

I was so confused when I heard that, "like... a HTML file?".

Keep going at this rate and we'll be using frames again.

> using frames again.

That’s pretty much what htmx is…

> "like... a HTML file?"

Serving a static HTML file is not server-side rendering.

It's much dumber than that. The people advocating for SSR want the server to respond with HTML generated based on whatever is in the request.

So like PHP?

This thread is so cope.

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.

Well React was born in Facebook which was famously PHP codebase. It makes sense.

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.

Oh please, I professionally use both daily, JSX is just PHP with more steps.

Though not JSX, with TSX you get type checking with your markup.

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

> The language is very unplanned, go look at an equality chart for PHP, it makes JavaScript blush as well.

This has been fixed in PHP 8. https://wiki.php.net/rfc/string_to_number_comparison

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

That… makes it even worse.

why?

Because now the behavior of comparison depends on whether the string looks like a number.

Arguably 48 == "48" should be true. If this doesn't work for you, stick to ===.

Thank you, I'll stick to languages where you can't just compare numbers and strings without an explicit conversion.

Also, should 48 == "48.0" be true? How about "048", "48.", "0x30", " 48 ", "48foo", "3*16", "XLVIII", "forty-eight"?

Once again: just use ===

If you decide languages based on minutiae like this, I can only pity you.

=== works for equality (if you actually remember to use it), but how about comparison? There's no strict version of <.

strcmp

I'd love to see a modern PHP without the language quirks and with a decent standard library.

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

And yet people seem to keep inventing variations of this as "templating" languages.

That presumably take care of the escaping rules and grammar of the output language, unlike the giant string concatenator that is PHP.

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

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.

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.

Xdebug?

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.

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 guess that means that JavaScript is McDonald's?

[0] https://en.wikipedia.org/wiki/List_of_the_largest_fast_food_...

> It's popularity is waning.

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 ?

There will be no golden age for anything using node.

That's a fun list.

Of over 100 I have only heard of 1/3: 35 in total.

I have only ever been into and eaten anything from half of those.

So fully 2/3 of the list I've never even heard of. Interesting.

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.