I think at some point you turn around and become relatively unbothered again. Or you have to if you're forced to work in languages lacking things you like from other languages and don't want to feel frustrated all the time. (Doing Java and JS for years I was able to reduce the frustration to only some of the time.)
Until Python 3.4, there were no enums blessed in the reference implementation, but that was fine for me. Is https://docs.python.org/3/library/enum.html really that much better than the examples in https://web.archive.org/web/20120207145701/https://norvig.co... ? More powerful, sure. But if we just wanted simple C++ enums and not structured Java-like enums it's hard to argue against the conciseness of RED,GREEN,BLUE = range(3) and moving on with what matters.
I guess two advantages of having something blessed by the language are 1) you don't need to think anymore or argue about whose workarounds (if any) are better, like the sibling's comment using PHP interfaces with consts inside, and 2) if the language isn't flexible enough to add the thing yourself, if the thing needs privileged status by the compiler or whatever, then you need the blessing for the best experience. My favorite language (Lisp) has no enums, but it's flexible enough to add them (and people have done so) in a way pretty indistinguishable from if they were there from the start, or of course you can use moral equivalents to the Python 2 examples without fuss. (Rather than just variables though there are also keywords or just plain symbols, which you can have type checked with deftype, and dispatch on with object methods if you like structured enums.)
Interesting. I had the opposite reaction towards using classes for this. Mainly because of a fear of misuse.
The more options a developer has the less likely he or she chooses the best solution to solve a problem. (Often best is in the eye of the beholder too, complicating things further)
Defiantly one of the best proposals for enums in PHP so far. It handles many of the needed requirements, reuses classes as building block so you get a type, can have methods or case specific methods, can implement interfaces, can be mapped to a primitive value and solves the problem with strict equality beautifully.
One problem is that an enum can't be an index key of an array. Read why in this reddit thread between the authors of the RFC.
> Inside a method on a Case, The $this variable is defined and refers to the Case instance.
Say what? Where does this instance come from and what is its scope?
> By default, Enumerated Cases have no primitive equivalent. They are simply singleton objects.
So, singletons. That way you end up with more global state, with all its consequences.
> the following features of objects are not allowed on enumerations:
> Enum/Case properties
Ok, so these are objects without properties. That could solve the global state problem but at this point you may just as well skip the entire object part as I don't see why exactly it's needed for an identity check.
Also, enumerations may have static methods but the provided example says "public function" without the static modifier.
>So, singletons. That way you end up with more global state, with all its consequences.
As you point out, the lack of properties solves that. The use of a singleton probably relates to the identity issue
> at this point you may just as well skip the entire object part as I don't see why exactly it's needed for an identity check.
PHP only has 8 types (string, int, bool, float, array, null, resource, object) and they're not likely to be added to (resource is largely deprecated).
Given that, object is the only one that's not likely to be abused by relying on the actual scalar value. Keeping it as a singleton ensures that === will still work (it requires 'same instance')
There's one more thing not addressed by the RFC: how to check for a particular enum to exist. The way I see it, a new function "enum_exists" would be needed and validating a QCN would become this ugly:
its implicitly addressed by saying enums map to objects and clarifying how "::class" works, i.e. enum_exists is not necessary, because its implementation would essentially be class_exists.
Ah, right. The assumption that "new ReflectionClass($qcn)" where "assert(class_exists($qcn))" works should still be valid as RefelctionEnum[sic] extends ReflectionClass.
I'm not completely certain on this, though. If not, it'd definitely break things.
What is the "monad-style behavior" they talk about relating to enums here? I really don't understand the connection, and nothing in the rest of the proposal makes any mention of it.
The draft there has a feature that the posted RFC does not. Associated types. Without the associated types you can't have the monadic style behavior which is why I was similarly confused by that wording there. Associated types elevates this from "Oh look a C enum" to actually useful ADT's like in Rust or the ML family of languages. I wonder if the draft you linked will make it into the official rfc or not.
I find it interesting that as the industry moves closer and closer to smaller, less complex, microservice style codebases, languages are moving in the opposite direction and creating more and more features and complexity designed to help handle large and complex codebases.
It’s almost as if language maintainers are removed from the practical applications that their language.
Language features generally solve problems users experience in real projects. Sometimes they do a better or worse job (see C++17 variant/visit in contrast), but the goal is virtually always to turn a larger, difficult-to-understand, complex, or error-prone set of statements into a smaller, easier-to-understand, simpler, resilient set of ones.
Complexity that isn’t solved in the language itself inevitably works its way into projects that use it, which is why abstractions and standard libraries exist in the first place.
The main feature I can think of that helps languages with larger codebases is static typing (Python, Typescript). Prior to Python type annotation, at a previous job, someone commented that Python didn't scale not because of performance, but because as you add more and more developers to a complex codebase, the lack of type safety ad growing codebase made safe changes hard.
Over in Java, a lot of the language changes are just syntactic sugar to make Java less verbose. Granted, Jigsaw is an exception, and JVM enhancements are good for everyone.
That enum methods cringe me, IMO they should try to make enum as dumb as possible, more like key-value pair, let the class/function handle the implementation details.
I have to wonder, how big is the overlap between people who understand and want to use algebraic datatypes, and people who program in PHP?
PHP’s main selling point has always been its low barrier to entry. Introducing high-level abstractions like ADTs will hurt that user group.
At the same time, I don’t think PHP can ever catch up with high-level languages that were built on less shaky foundations (and cleaner syntax). So what’s the end goal here?
Honestly, I think people focus on the new PHP developers and the part time hobby developers and think only about that group when it comes to PHP.
I think we as a whole need to understand that once you get to doing PHP professional for several years the skill level and the requirements are roughly the same for most programming languages.
The company I work for is part of a large multinational company. The parent company decided to merge two of their children companies together since they operate in the same market. Sadly the two companies provide two different things in the same market and very few things overlap. When they did the merger and then COVID struck they decided they needed to get rid of developers, they took the approach that seems to be that the PHP developers were the weaker developers. So they got rid of the majority of them leaving only the ones they legally couldn't get rid of. The result, they now need to rewrite a system with only the Java and Kotlin devs who lack the fundmental business understanding of the system they need to rewrite. They also are stuck with a group of developers whose code is of a lower qualtity, that fear deploying anything at anytime on a Friday, that lack the understanding of how to build distributed systems while operating a distributed systems, who wrote systems that the day they went into production were scheduled to be rewriten because they simply weren't up to scratch with the requirements, and with a system that is labelled as scalable but can't scale as well as the system written in PHP it's meant to replace .
Trying to evaluate the needs, skills, and undestanding of developers based on what language they're currently writing in is not the wisest of moves. Evaluating a system base on the language it's written in is equally unwise.
Overall, I think PHP can compete with many languages and beat many languages in the web development area. In the areas such as data processing, concurrency, and system processes it's generally lacking due to the fact it's main selling point is building websites.
>I have to wonder, how big is the overlap between people who understand and want to use algebraic datatypes, and people who program in PHP?
The same as people who understood functional programming, async/await/generators/ummitabilily/etc and who program in JavaScript?
JS was seen as for the lowliest of developers, but it has adopted (and people use) all those kinds of things.
Understanding is often a function of availability and/or fashion, and there's not some inherent reason PHP programmers are "dumber".
>At the same time, I don’t think PHP can ever catch up with high-level languages that were built on less shaky foundations (and cleaner syntax). So what’s the end goal here?
On one side, it already has (caught up).
On the other side, the point is moot. The end goal is that it's a very succesful language with millions of programmers and billions in projects done with it, and its team wants to keep improving it.
What did you imagine as some "end game"? Getting the node of approval from Haskellers?
> PHP’s main selling point has always been its low barrier to entry
While this is 100% true (though latley more true for Python), the people who started using PHP years ago and stuck with it over the years have now gotten the tools for a more precise and structured code base.
I personally use PHP even on servers for quick scripting of things because I never learned Python well enough to have all functions at my finger tips and don't get me started on powershell ;D
The overlap is probably in framework builders, and that trickles down a bit to the users who like to use them and some of the users forced to use them. I wonder if "I don't need a framework" gets you crazy looks in the broader PHP world today? Going no-framework was already increasingly out of fashion as of around PHP 5.3 (when I got out and stopped bothering to learn the new updates -- my last project used the Yii framework) so it wouldn't surprise me. Sure there's still the old practical business-needs-first PHP, I was able to update some old PHP to v7 without much fuss, yet it's more than just out of fashion it's ripe for any consultant or new employee looking to make a name for themselves to "clean up" and get with the times. Younger me would probably cringe but I'd just advise to use Java instead of modern PHP with all its bells and whistles and patterns, there seems to be little difference anymore.
I have worked with many bright people whose day job was programming in PHP. In their free time, some maintained Haskell libraries, others wrote libraries facilitating pure fp in PHP.
As someone who does PHP back-end work every day --- the lack of enums is probably my #1 complaint with PHP as a language these days and I probably find myself wishing I had access to them at least once a week.
You do have a point, I’m not the biggest fan of JS either. But notice that var is linted out of every modern JS codebase. Where’s PHP’s equivalent of let/const?
Also, I think a huge part of JS’s staying power was that besides its obvious warts, it always had a solid FP foundation as well. JS was one of the first mainstream languages with full closures. That was a powerful tool for building abstractions right from the start, and I don’t think Node.js would have happened without this.
Equivalent of let/const for PHP would be manual use of include/require when loading php files, modern code bases rely on an auto loader.
There are some legitimate use cases of manually loading a php file, e.g loading the auto loader, but that is usually the exception and not the rule today.
Well php has actual constants that are.. constant. So if you’re asking for an equivalent misleadingly named feature, it’d be people declaring properties with an underscore rather than just making them private.
PHP is designed that you can use the functionality you need and sub functionality to a functionality is usually also optional, e.g. you can use functions if needed and with functions you can have typed input parameters if you like, in many ways similar to TypeScript, you expand as you go.
There is nothing in PHP that forces you to code in a certain style, like in other languages, it is truly multi paradigm.
Why can’t you be a competent programmer that codes in PHP and also understands ADT? Where is that defined?
When I read comments coming from people who don't use PHP which are always negative or condescending, I wonder - how do you imagine programmers who use PHP are like? Do you immediately draw parallels in your mind that makes us PHP-ers incompetent and basically dumb, while having a language that lets you mash the keyboard and it works?
Honestly, after having used most of the languages at my disposal for past 22 years I've been doing this job - they were nothing special compared to PHP (or PHP compared to others).
You still have to figure the problem out before solving it with algorithms. No language or framework will help you do that.
I'm keen to hear why there are comments that demean one tool and elevate the other, when in reality - they're all just programming languages.
My comment was not meant to be demeaning, sorry if this was not clear. I used PHP 4 and it was okey, albeit pretty inconsistent. However, programming languages are a very competitive space. It is extremely expensive to keep them and their ecosystem alive. My sense is that, unless a language keeps up, it will go down. Not in the sense that it will disappear overnight, just less favoured every time a Greenfield project starts.
My subjective analysis is that each language has a niche that if fills nicely:
- C - no BS, no runtime, close to hardware.
- C++ - a bit further from the hardware, a bit closer to the developer.
- Python - glue the two above with few lines of code. Go-to language for "data pipelines".
- NodeJS - one code, can run both in the browser and on the server. Go-to language for web development.
- Java - one syntax, runs both on Android and on servers.
- C# and Go - vendor-evangelised languages. Supported by huge vendors and their network of partners.
- COBOL - too big to fail :))
I honestly don't get what niche PHP fills. Why would anyone choose PHP over another language? Developer pool? Ecosystem of libraries? Evangelized by a vendor? Front-runner in new concepts? Too big to fail?
I imagine programmers who do not place a high value on the impact that their tools have on their ability to think through problems effectively.
I am not saying that you are dumb. I am saying that your values clash with my needs.
This clash is so strong that I predict that if I again try to program professionally in php and its frameworks, the interaction would again have a disastrous impact on my mental health, my livelihood, and my marriage.
-----------------------------------
Let's suppose you enjoyed baking bread, but someone rejected your work and told you that gluten gives them terrible intestinal pain. You would have a choice:
1. Conclude they're being overdramatic and be offended by their rejection.
2. Believe their self assessment, move on, and continue with your craft.
-----------------------------------
(They would have a similar choice whether or not to come into a threat about baking and yell at people about gluten)
> This clash is so strong that I predict that if I again try to program professionally in php and its frameworks, the interaction would again have a disastrous impact on my mental health, my livelihood, and my marriage
> Let's suppose you enjoyed baking bread, but someone rejected your work and told you that gluten gives them terrible intestinal pain
Both these examples are ones where the problem isn't the tool, rather, the person using it. It's not really PHP (or the bread) being critiqued is it?
Right. PHP is not the problem. Nor is the bread, or the connectors, or the husband/wife. That is exactly my point - you are leveling a criticism at yourself and your own inability to use a tool.
This is wholly unrelated to the quality of the tool itself or the other practitioners who choose to use it. It is therefore a bit offensive that the conclusion you draw is that developers who use PHP must have a deficit in their ability to work through problems.
The “problems” do not change based on which language is chosen to solve them. That is, if you actually understand the “problems” in the first place...
> It is therefore a bit offensive that the conclusion you draw is that developers who use PHP must have a deficit in their ability to work through problems.
That is distinctly and meaningfully different from what I said.
I did not say PHP developers have a deficit. I'm saying the PHP community has certain values and approaches problems with a certain perspective.
I see PHP developers as those whose perspective does not highly value the interaction between how a tool is shaped and its users ability to use the tool to think through problems. A programmer with this perspective might say that a tool's usability in a context is wholly unrelated to the quality of the tool itself or the community of other practitioners who choose to use it.
> I'm saying the PHP community has certain values and approaches problems with a certain perspective
What are those values and what is that perspective? Your argument is getting rather hand-wavy. I'm not entirely sure what I would be arguing if I attempted to disagree.
Without a more concrete formulation my current hypothesis is that you are simply disguising your ignorance as projection.
If you attempted to disagree, you would have to argue one of the following:
A. The following is not a common perspective among the PHP community: "Problems do not change based on the language chosen to solve them. Inability to use a tool is wholly unrelated to the quality of the tool itself."
B. That perspective has absolutely zero impact whatsoever on the choices of tooling, frameworks, automated tests, and code found in an unknown team's PHP codebase.
C. Whatever impact that perspective does have on the differences between a Python codebase and a PHP codebase will not meaningfully impact the productivity of /u/afarrell.
D. Therefore, it cannot be the right personal choice for /u/afarrell or another developer to avoid PHP. Do not leave money on the table for /u/kingdomcome50 or /u/tux.
------------------------------------------
If your response to this is "Huh? Sure, whatever. Different people are different. Make your own personal choices. It's a free country." then that is 80% of my point.
The other 20% is: Lack of self-knowledge and the inability to give/take a rejection will lead you to do things that are not healthy for you.
Don't eat lasagna if you're lactose intolerant.
Can we please stop acting like 'I do not want to write code in X language' is a personal attack on the intelligence of those who _do_ work in X language?
> When I read comments coming from people who don't use PHP which are always negative or condescending, I wonder - how do you imagine programmers who use PHP are like?
Your answer:
> I imagine programmers who do not place a high value on the impact that their tools have on their ability to think through problems effectively
Even in the most charitable of circumstances it's hard to read your words in a way that isn't a slight against someone who chooses PHP. Especially when taken in the context of the discussion to which you are responding. And even more so because you have yet to substantiate (or even define) that claim in any meaningful way.
I have no problem with someone who doesn't like PHP (or any language). I don't particularly like PHP. And you know what? I hate python! But I am not making sweeping generalizations about those who program in python and whether or not they value their "ability to think through problems effectively"[0]. Mostly because that claim would make no sense at all...
It's hard to rationalize your answer above to mean anything like "Don't eat lasagna if you're lactose intolerant", so forgive me when I say that you are the one acting. Hey! I get it. You don't like PHP and you took a cheap shot at it. We all do it. The "PHP sucks" trope is hard to resist! But don't act like that isn't what happened. Have some self-knowledge and take the rejection. It's healthier that way.
> you have yet to substantiate (or even define) that claim in any meaningful way.
Sure.
To define my claim more clearly:
1. There is a set Q (Programmers who believe that tools have a negligible impact on a programmer's ability to use that tool to think through problems)
A set Q's belief in the low impact of tools is expressed by statements like:
- "You still have to figure the problem out before solving it with algorithms. No language or framework will help you do that."
- "you are leveling a criticism at yourself and your own inability to use a tool. This is wholly unrelated to the quality of the tool itself"
- "The 'problems' do not change based on which language is chosen to solve them."
2. There is a set P (programmers who prefer to choose PHP)
3. My first claim is that a member of set P is likely to also be a member of set Q. PHP developers are likely to believe the things that people in this very subthread are saying.
Do you still find my first claim unclear, insufficiently-supported, or offensive?
What does a "tool that allows you to think through problems" look like? This claim is unsubstantiated. You have provided nothing to discredit an assertion that no such tool exists, and certainly haven't provided any criteria by which your claim could be falsified.
Your claim is:
1. Such a tool(s) exists -- how can I know?
2. PHP is not one of these tools -- why not?
3. PHP practitioners don't value these tools -- huh?
It's a total non-sequitur.
Your criticism reads as "PHP solves problems differently than how I want to solve them". That is a totally reasonable opinion to hold (many do)! That's not really a reflection of PHP, it's a reflection of yourself. And that's okay! You don't have to like PHP. But it is a little offensive to try to justify your preferences in a way that passes sweeping judgement over anyone who programs in PHP. Especially when your argument insinuates that PHP programmers must have a deficit in their ability to think through problems...
To suggest that such tools exist, that these tools impact one's ability to effectively(!) think through problems, and that PHP programmers simply don't value these tools does insinuate a belief that PHP programmers are in some way unable to effectively think through problems. A broad claim indeed! Add to the above that you are unable to define, identify, or in any way clarify what criteria you are using to classify these tools, how it is they impact a person's ability to effectively think through problems, and why PHP is not one of them... and we are left with an obvious conclusion: you don't know what you are talking about.
Suggesting that PHP doesn't allow you to effectively think through problems, while certainly ripe for some fleshing out, is very different than saying PHP programmers (other people!) don't value tools that allow them to effectively think through problems.
We call my first paragraph ignorance, and the second projection. Turns out I was right!
At the end of the day any answer to a question asking why people condescend PHP programmers that doesn't dismiss the premise is itself condescending (or at the very least an admission thereof).
> "Why do you condescend PHP programmers?"
> "They don't share my values."
That's essentially your argument. Well... that's not really an argument is it? What are their values? What are your values? Why is one set better than the other? And most importantly, why does this lead to condescension?
The answers to the above, as I pointed out in my original comment, lead to only one conclusion: you've only identified a deficit in yourself.
Yes, I _do_ think that you don't value something you consider fictional.
> any answer to a question asking why people condescend PHP programmers that doesn't dismiss the premise is itself condescending.
If that was the mindset you started with, then my attempt to give a nuanced answer the question was doomed from the start.
> you've only identified a deficit in yourself.
Yes, identified a deficit in myself which, much like lactose intolerance or celiac disease, applies in some situations. This whole thread is additional evidence that trying to communicate with PHP developers about cognitive processes is one of them. The right response for me is to avoid that.
I'm not a PHP developer! And you have therefore made my point repeatedly. You have come to believe something about me in total ignorance.
Why don't you provide me with some non-fiction? I've asked repeatedly if you could delineate what a "tool that allows you to effectively think through problems" might look like, but the only answer I have received so far is "I don't have to". Very convincing!
Of course we both know that you won't because doing so would move the concept out of your head (where it is just a prop) into this discussion where, inevitably, it will be shown to be insufficient to your argument. You need to hold onto it because it is the only straw you have left. I understand your unwillingness to be made a fool. You are a poker player who insists they have won the hand, but refuses to show their cards. Unfortunately I'm calling your bluff!
I've had you nailed down on this since your very first comment and here we are, days later, and you have yet to substantiate your claim beyond "I believe it to be true". A true work of cognitive genius! Or is it dissonance? It's always interesting to see which of my thoughts garner a response. I'll take a page out of your playbook and make a prediction myself:
A) You will continue to avoid to substantiate your claim and focus on something else entirely.
B) You will substantiate your claim by providing only criteria to which PHP does not meet (e.g. "multi-threaded") without providing any information as to how those criteria support your premise (essentially arguing "not PHP" in more words).
C) You will not respond at all.
At this point I think you are right. The answer is C! Sometimes you are overmatched and it's best to just avoid the interaction. It's healthier that way. Good luck!
@kingdomcome50, The “problems” do not change based on which language is chosen to solve them. That is, if you actually understand the “problems” in the first place...
Generally, no. I only slightly understand the problems when I start.
I need tools like a programming language which helps me think through the problems more deeply over time and automated tests which help me safely refactor as I learn more about the problems.
I think the PHP community has other priorities driven by other values, like being able to start a project and publish to the web quickly.
I think this means that I personally should not choose PHP.
No, I don’t imagine that. But the fact is, PHP is very verbose and missing a lot of tools for building good abstractions compared to richer languages. If you’ve used “most of the languages” (whatever that is supposed to mean) and not realized this, I recommend you read up and reflect on the Blub Paradox:
I'm sorry, but it seems like you haven't used PHP and are actually in the dark about what language features there are. I wrote "most languages at my disposal", I didn't want to go down the path where I basically throw buzzwords and brag in front of someone I don't even know.
Don't get me wrong, but you don't seem interested in discussing, you rather appear to want to show how right you are without iota of PHP knowledge.
Since there's no dialogue here and you appear to be yet another code plumber, I'll bid you farewell and I wish you all the best in your career.
> If you're writing a program that only has to do something very simple, like number crunching or bit manipulation, you may as well use a less abstract language, especially since it may be slightly faster.
In your opinion, what percentage of web applications do you think are non-trivial?
And for what it’s worth, nobody chooses PHP because of the language. That’s not the selling point. The selling point is the development paradigm/runtime. It’s dead simple.
I recently started a small web project using the SAFE stack:
I urge you to follow that QuickStart yourself (it only takes a minute or two).
Assuming you were actually able to build the project, now, look at your project structure. How many directories do you have (11)? How many files (15510)? Think about how much knowledge is required to understand what’s going on (if you’ve never touched F# you are probably lost).
What does this QuickStart app do? It is, I kid you not, a “Todo list”!
I could write an almost exact clone of this app using PHP in exactly 1 file. No configuration scripts. No build suite. No 3rd-party packages. No CLI commands. Just 1 PHP file. Thats why people choose PHP.
Yup. So is C++, as is FORTRAN, and even COBOL (although I don’t think they are actually adding to COBOL anymore).
All of these languages are favorite targets of mockery by the “buzzword du jour” crowd, but they persist.
I like modern stuff, and don’t miss some of the old crud, but there’s something to be said for a language that is over a quarter-century old, and runs a considerable portion of the world’s infrastructure. I think C++ was introduced 35 years ago, and FORTRAN is about 30 years older than that.
And, of course, you have C, which is the engine behind Linux and Git.
I was specifically refering to PHP. C++ has picked up a lot of speed since 2010, and kept up with modern needs, such as concurrency. C fills the need of being no BS, no runtime, close to hardware. COBOL and FORTRAN are too big to fail.
Why would anyone pick PHP for a new project over, say, Python or NodeJS?
Because I wanted as many non-technical people as possible, running on wing-and-a-prayer, bottom-tier, shared hosting plans, to be able to run the platform I developed.
Why are we even talking about C/C++. This languages are not intended for web. This is software languages. I would never use C/C++ to code a website project. Just like I would never use PHP to code a software. Better comparison would be PHP vs Python or Ruby for example.
It’s not a question of age, and I think you’re comparing apples to oranges a bit.
Cobol is simply kept running. Everything it does, newer languages do better. Nobody writes new systems in it.
C++ on the other hand allows you to do things that other languages simply don’t, so of course it’s still alive. New C++ projects are started every day.
A lot of actively developed languages have their niche. Python looks very elegant to mathematicians and engineers, and has fast math libraries. Java has an unmatched ecosystem. And so on.
I think PHP's niche is low barrier to entry. Maybe I'm wrong, what do you think PHP does better than other languages?
(Edit: Sorry for editing the post while you replied. I tried to word the question in a more friendly way.)
PHP mostly competes with Ruby, Python and Node in the web space.
It is generally faster than Ruby and Python.
It's not the mess that javascript is.
Has a sane community with a wide range of well-maintained packages.
Symfony is easily a rival to Django and RoR. At that point it's a matter of preference, but Symfony is top-notch quality. I wouldn't care for the ActiveRecord usage in RoR for example.
I'm not sure that people saying low barrier to entry know what they're talking about. It's the same barrier to entry as for any other scripting language. If you're telling me about FTPing files: this is not how the PHP community has been working for the last ~10 years.
All those people commenting "I have no idea who would start a PHP project today" live in a bubble, probably based in SV.
The language has a lot of stuff that drives me nuts (in reality, it's not much of a drive –more of a short putt [Ed]).
But it is quite performant, stable and capable. I have done a lot of PHP programming, and would be very happy to never work in it again. I have a tremendous respect for the language.
It also has –literally– tens (if not hundreds) of thousands of expert developers, worldwide. Many of these developers used to stink, but are now much better, as a result of their work with PHP.
It also has a massive support infrastructure.
HN doesn't really appeal to the types of developers that make the lions' share of PHP (and C++) implementation base, so you won't always hear about it, hereabouts.
I remember reading an article, some time ago, called "IT Runs on Java 8"[0]. It talked about how much of the IT landscape is composed of folks working in tech and patterns that are not considered "shiny/sexy."
[UPDATE]: Not a problem. I do the same thing ;).
The main thing that PHP has, that very few other languages have, is a gigantic implementation surface. In one of my more successful open-source projects, I deliberately wrote it in PHP (4, then, reluctantly, 5.6), because I knew that would give it a far better chance of being implemented.
I was right. It is now fast becoming the de facto world standard for its demographic.
>what do you think PHP does better than other languages?
Most of the time is not language A vs language B in abstract, it really depends on the project and what experience you or your developers have.
Let me give an example that is not web development. We had a desktop app and we had a feature where the user can submit feedback or bug reports. This feedback was stored and managed in a third party product that had an API, we could not call this API directly from the application because we did not want to put our keys in the app. So we had to put 1 php file on our server that contain the secret key, we done a POST from the app to the server and the script would validate and then connect to the API. I am imagining that some people today would solve this with some super engineered containers or micro services but the solution I used with just 1 file with a few lines of code could be implemented in a few minutes by a developer and maybe 1 or 2 hours by some competent non-developer.
Good use of PHP I'd say, but as usual its strength really is that it's so easy to execute on any server. If you already had, let's say a Node backend, it would have been easier to just add an endpoint for this. The language itself, while I had no hate for it, doesn't have much advantages over Python/Ruby/JS/TS/other.
Sure, and for different jobs I used other languages.
For one task there was a great python library so we use python and sent to it requests from PHP , some other task there was a java executable that worked the best so I called it from PHP, some other tasks there were Linux CLI tools that worked best so I called those, and some other task needed to use node and puppeter(a Chrome) wrapper - it was crashing a lot so we put it on a different server and called it from the main server PHP project.
So in real world projects you don't chose the tool based on coolness factor, if you want to solve a problem in the best way possible you need to use the best tool for the job.
When I built a small, internal tool a few years ago, I couldn't believe it still didn't offer something as basic as an enum type.
Didn't bother me when I learned PHP4 as a kid, but studying CS and becoming a professional developer really changes what one expects from a language.