A personal anicdote, but I run a SaaS, and there is an extremely pronounced (negative) difference in the sophistication of technical support queries asked by PHP devs vs those in other languages. This may be because PHP is so ubiquitous and approachable, but these types of silly questions (how do I make a POST call to your API?) are why PHP gets it's reputation.

Yes, the biggest strength of PHP is that anyone can pick it up quickly... which means anyone will. There are "best practices" but they're not necessary to get the job done.

I usually recommend that new developers start with Python. It teaches structure and consistency without as much variation or room to screw up.

Tell people to code it in Java or C, preferably in vim.

Advantage: they'll never create a mess that you'll have to maintain.

/s

Yes, I totally agree with you: the advantage of PHP is that anyone can pick ut up, and they have done.

The question was often never if it should be coded in PHP or Java but if it should be coded at all and, if so: if it should be an excel file on a file share or sent in email or a php script.

Disclaimer: PHP and Java coder. I can get stuff done quickly in Java, but it takes some practice.

I'll agree that what makes a good language is subjective, and that most all languages have their problems. There is a certain threshold where "good enough" is what matters.

Personally, I'd rather everyone just stop the good/bad language debates entirely.

Programming has to be the only environment where the voices of academia don't seem to matter because "my language gets shit done". Deep inside, what do you think those researchers in the PL community, the people that know the ins and outs, that theorize about languages, the people who spent years and years learning about the theory behind it all, who created the OCamls, the Haskells, the Coqs, the Idrises and so forth, what do you reckon their opinion of PHP is?

So really I don't think "good language" is subjective. PHP is not fast, it's not well-designed, it's not particularly terse, it doesn't have particularly great tooling (Facebook has made that better with their HHVM initiative in all fairness), it isn't consistent and easy to reason about and the worst offender of all, it doesn't offer a dramatically different or original model of thinking about programs.

What is has going for it has nothing to do with the language itself: jobs, ecosystem and easy hosting. I totally agree that a good language is whatever works for you, but in the meantime, "whatever is good enough" is a mindset that doesn't help us strive for something better, which does matter if we're going to collectively spend decades in this line of work.

> Programming has to be the only environment where the voices of academia don't seem to matter because "my language gets shit done".

Wrong, otherwise we would have this discussion in Esperanto.

Sometimes Real Life (TM) experience beats clever design. PHP was first, has iterated, always had a niche and is now better than ever. Not good but good enough to save people a lot of work.

> PHP is not fast

Actually, it is.

https://benchmarksgame.alioth.debian.org/u64q/php.html

I don't quite grasp your logic. That comparison only means that PHP is faster than other slow languages. Being faster than slow doesn't mean you're fast.

> it doesn't offer a dramatically different or original model of thinking about programs.

In PHPs niche this should be in the advantages section.

Hi Veejay, I do not know for how long or just how intensely you have been in contact with the "academia" so far, but let me tell you this: however much a certain solution is promoted in academic circles has close to nothing to do with how useful it actually is to general (programming) society. The average academic bases his assumptions of what makes a language "good" or "bad" on 6-12 months of internship at a medium sized company (preferably in a mgmt/assistant position), some tutorials he went through and 5 years of theorizing with a professor who did his last serious programming work back in the 1980s. Granted, this approach sometimes yields exciting innovations that might someday be adopted by real world applications. But this does and will not make Haskell and OCaml appropriate for the other 95% of problems developers have to solve.