P++ idea: FAQ(wiki.php.net)
wiki.php.net
P++ idea: FAQ
https://wiki.php.net/pplusplus/faq
93 comments
I do not mean to be rude or offensive but are there plans to fix the half-baked type system?
I am using PHP7 at work and the ability to annotate functions with types is a good idea until you get arrays which can take anything (so you can have an array of who-knows-what) so you can't assume further down the call stack that you're dealing with a known type so have to test what you're dealing with, or objects.
It's a bit of a mess to me and makes reading the code very difficult without running it in a debugger to step through what you're dealing with. Generics or some form of strong typing (which seemed to be what the type annotations and return value types hinted at) would really help, particularly with large projects. I am coming from a C++ background.
Any pointers or tips or documentation for me would be welcome.
If P++ pushes some of this strictness further onto the language then great. It saves me having to do it in code.
I am using PHP7 at work and the ability to annotate functions with types is a good idea until you get arrays which can take anything (so you can have an array of who-knows-what) so you can't assume further down the call stack that you're dealing with a known type so have to test what you're dealing with, or objects.
It's a bit of a mess to me and makes reading the code very difficult without running it in a debugger to step through what you're dealing with. Generics or some form of strong typing (which seemed to be what the type annotations and return value types hinted at) would really help, particularly with large projects. I am coming from a C++ background.
Any pointers or tips or documentation for me would be welcome.
If P++ pushes some of this strictness further onto the language then great. It saves me having to do it in code.
> until you get arrays which can take anything
There's a widely-used PHPDoc standard for annotating arrays: `Foo[]`, and there are at least three PHP static analysis tools that can correctly interpret those annotations: Psalm (https://psalm.dev), Phan (https://github.com/phan/phan) and PHPStan (https://github.com/phpstan/phpstan).
Phan and Psalm also support a docblock syntax for generics - I wrote about it here: https://medium.com/vimeo-engineering-blog/uncovering-php-bug...
There's a widely-used PHPDoc standard for annotating arrays: `Foo[]`, and there are at least three PHP static analysis tools that can correctly interpret those annotations: Psalm (https://psalm.dev), Phan (https://github.com/phan/phan) and PHPStan (https://github.com/phpstan/phpstan).
Phan and Psalm also support a docblock syntax for generics - I wrote about it here: https://medium.com/vimeo-engineering-blog/uncovering-php-bug...
Thanks for this! This is just what I was looking to know
Thanks!
Thanks!
How is PHP pragmatic compared to other languages? Do tell.
Instead of having a trillion build steps, you write PHP right in the HTML.
It’s so easy to teach. Learninh html css and php is such a win. Quick to bash out a simple site.
> Quick to bash out a simple site.
This is precisely why I don't think it's the appropriate tool for any substantial, serious, or long-lived projects. The language feels kludgey, and it attracts an ecosystem of beginners that don't necessarily have to learn much in the way of CS fundamentals or engineering to succeed. (Indeed, I've run into more than a few that don't know the difference between lists and dictionaries or the runtimes of the operations performed on them.)
It's not that I think that a language should be a barrier, but I've wasted so much time reading confusing and poorly-written PHP code, and it feels like the language actively empowers code to be written this way. A tool should also teach. There are other languages that have this problem as well (C++ comes to mind), but I think they tend to be hard enough to use that practitioners already understand the do's and don't's.
I know it's irrational of me to be so irate that this language is still active, but it bothers me that real engineering work and human productivity is spent on supporting one of so many scripting languages that are marginally different. I suppose I should be even more angry at all the cognitive effort being put into marketing and adtech, but PHP makes me sigh.
This is precisely why I don't think it's the appropriate tool for any substantial, serious, or long-lived projects. The language feels kludgey, and it attracts an ecosystem of beginners that don't necessarily have to learn much in the way of CS fundamentals or engineering to succeed. (Indeed, I've run into more than a few that don't know the difference between lists and dictionaries or the runtimes of the operations performed on them.)
It's not that I think that a language should be a barrier, but I've wasted so much time reading confusing and poorly-written PHP code, and it feels like the language actively empowers code to be written this way. A tool should also teach. There are other languages that have this problem as well (C++ comes to mind), but I think they tend to be hard enough to use that practitioners already understand the do's and don't's.
I know it's irrational of me to be so irate that this language is still active, but it bothers me that real engineering work and human productivity is spent on supporting one of so many scripting languages that are marginally different. I suppose I should be even more angry at all the cognitive effort being put into marketing and adtech, but PHP makes me sigh.
>> Quick to bash out a simple site.
> This is precisely why I don't think it's the appropriate tool for any substantial, serious, or long-lived projects
This is precisely why it is an appropriate tool - those simple sites become more complicated, and eventually they're Tumblr or Etsy or Wikipedia or what-have-you.
> it feels like the language actively empowers code to be written this way.
I've felt the same thing, especially early on. I think there are two reasons:
- a lack of a compile step means you're never forced to conform to someone else's idea of how your code should work (though running a static analysis tool fixes this).
- additionally, PHP's interpreter is designed to soldier on in situations where other runtimes would exit (e.g. when it encounters an undefined variable or array offset). While I can imagine justifications for this behaviour, it allows for a lot of bad code.
> This is precisely why I don't think it's the appropriate tool for any substantial, serious, or long-lived projects
This is precisely why it is an appropriate tool - those simple sites become more complicated, and eventually they're Tumblr or Etsy or Wikipedia or what-have-you.
> it feels like the language actively empowers code to be written this way.
I've felt the same thing, especially early on. I think there are two reasons:
- a lack of a compile step means you're never forced to conform to someone else's idea of how your code should work (though running a static analysis tool fixes this).
- additionally, PHP's interpreter is designed to soldier on in situations where other runtimes would exit (e.g. when it encounters an undefined variable or array offset). While I can imagine justifications for this behaviour, it allows for a lot of bad code.
> The language feels kludgey, and it attracts an ecosystem of beginners that don't necessarily have to learn much in the way of CS fundamentals or engineering to succeed.
Reminds me of people complaining about JavaScript over the years, yet we pulled through, the language is better and most importantly, we're making money writing it.
Reminds me of people complaining about JavaScript over the years, yet we pulled through, the language is better and most importantly, we're making money writing it.
>> we’re making money writing it
So did they in PHP.
So did they in PHP.
you write PHP right in the HTML.
I hope this comment was meant to be ironic. Because that mindset demonstrates everything that is wrong with PHP and its community regarding engineering practices and security.
I hope this comment was meant to be ironic. Because that mindset demonstrates everything that is wrong with PHP and its community regarding engineering practices and security.
I think if you're going to make a statement like that you need to be prepared to provide an argument to back that up.
Ten years ago if you had told me we'd be interpolating HTML into javascript I might have said the same thing, yet here we are with React/JSX. It's not only common, it's generally regarded as good engineering.
Ten years ago if you had told me we'd be interpolating HTML into javascript I might have said the same thing, yet here we are with React/JSX. It's not only common, it's generally regarded as good engineering.
A terrible and incorrect comparison. JSX is a templating language. Your logic still lives within a JS component.
Op is proposing that PHP be embedded directly in HTML. That obviously has maintainability and security issues. WordPress is a good example.
Op is proposing that PHP be embedded directly in HTML. That obviously has maintainability and security issues. WordPress is a good example.
> [Embedding PHP in HTML] obviously has maintainability and security issues.
Honestly, I'm not sure it does. The two main security issues in typical PHP software are cross-site scripting and SQL injection, and both of those could be solved with better API design. (For example, PHP could use something similar to Rails's `html_safe` to make it harder to accidentally include untrusted HTML in the page.)
As far as maintainability goes, I'm not sure what makes PHP uniquely bad in this area. It seems like you could write a bad, unmaintainable React app in pretty much the same way you write a bad PHP app -- by eschewing MVC and sticking everything in the components/templates.
Honestly, I'm not sure it does. The two main security issues in typical PHP software are cross-site scripting and SQL injection, and both of those could be solved with better API design. (For example, PHP could use something similar to Rails's `html_safe` to make it harder to accidentally include untrusted HTML in the page.)
As far as maintainability goes, I'm not sure what makes PHP uniquely bad in this area. It seems like you could write a bad, unmaintainable React app in pretty much the same way you write a bad PHP app -- by eschewing MVC and sticking everything in the components/templates.
Honestly, I'm not sure it does.
Of course it does. Less maintainable code is always less secure.
Embedding PHP business logic in HTML makes it much easier to accidentally dump confidential state into the response.
Sticking everything into a component does not completely eschew MVC. You are still forced to bind values to a template.
Mixing PHP and HTML without a template engine provides no guarantees.
The responses here from PHP devs reaffirm my beliefs about how haphazard and sloppy PHP devs are.
Of course it does. Less maintainable code is always less secure.
Embedding PHP business logic in HTML makes it much easier to accidentally dump confidential state into the response.
Sticking everything into a component does not completely eschew MVC. You are still forced to bind values to a template.
Mixing PHP and HTML without a template engine provides no guarantees.
The responses here from PHP devs reaffirm my beliefs about how haphazard and sloppy PHP devs are.
> Embedding PHP business logic in HTML makes it much easier to accidentally dump confidential state into the response.
There's no reason confidential state will get dumped into the response unless your PHP settings are completely misconfigured.
There was a time when PHP had very insecure defaults and that sort of thing would happen regularly especially in shared hosting environments where you had limited control over the configuration. That was a long time ago.
I haven't worked on a PHP project in about 5 years, but I have seen well maintained PHP code. There's a lot of reasons to gripe about the language but this isn't one of them.
There's no reason confidential state will get dumped into the response unless your PHP settings are completely misconfigured.
There was a time when PHP had very insecure defaults and that sort of thing would happen regularly especially in shared hosting environments where you had limited control over the configuration. That was a long time ago.
I haven't worked on a PHP project in about 5 years, but I have seen well maintained PHP code. There's a lot of reasons to gripe about the language but this isn't one of them.
Wrong. Other languages require templating systems that won't allow you to dump variables because they won't be in scope in the first place.
Using PHP in HTML allows you to do just that.
Using PHP in HTML allows you to do just that.
Uh, no - templates are scoped to the function or method in which they are called. They are only global if you include the template globally.
class MyTemplate {
function displayTemplate() {
include 'mytemplate.php'; // mytemplate.php has access to only class properties.
// Anything declared within mytemplate.php is scoped to the displayTemplate function.
}
}Uh, that is a contrived example not suggested by the op.
You can still embed PHP into HTML.
You can still embed PHP into HTML.
> Other languages require templating systems that won't allow you to dump variables because they won't be in scope in the first place.
This isn't true of every templating system in popular use. Rails's Action View, if I recall, allows you to stick <%= ENV["THE_DATABASE_PASSWORD"] %> into a template with no fuss at all, and yet Rails developers somehow manage to avoid doing that.
PHP isn't bad because it lets you put code in HTML, it's bad because the default behaviors and APIs it provides make it easy to shoot yourself in the foot. A better, safer language could keep PHP's ease of deployment without its issues. Maybe P++ will be that language and maybe it won't.
This isn't true of every templating system in popular use. Rails's Action View, if I recall, allows you to stick <%= ENV["THE_DATABASE_PASSWORD"] %> into a template with no fuss at all, and yet Rails developers somehow manage to avoid doing that.
PHP isn't bad because it lets you put code in HTML, it's bad because the default behaviors and APIs it provides make it easy to shoot yourself in the foot. A better, safer language could keep PHP's ease of deployment without its issues. Maybe P++ will be that language and maybe it won't.
That's not the same. I have seen plenty of unmaintainable PHP code that embeds business logic in HTML.
PHP was originally invented to be a templating language. Your templating logic can still reside in a PHP file, function, or class, the same way it can in javascript with JSX.
WordPress isn't bad because it uses PHP as a templating language (I think it's just the go-to "bad PHP codebase" example people use without really understanding why they are citing it). It's bad because it has competing code patterns that it evolved over time because it has to maintain backwards compatibility with an entire plugin ecosystem that is now decades old.
WordPress isn't bad because it uses PHP as a templating language (I think it's just the go-to "bad PHP codebase" example people use without really understanding why they are citing it). It's bad because it has competing code patterns that it evolved over time because it has to maintain backwards compatibility with an entire plugin ecosystem that is now decades old.
That is not true. I had to work with WordPress years ago, and one of the reasons it was so terrible is that it went to great lengths to mix view and business logic by interspersing PHP with HTML all over the place.
Yet React projects mix view and business logic by design and aren't usually that confusing to make changes to. That's not the reason the WP codebase is bad.
MVC does not mix view and business logic.
React isn't MVC.
React is MVVM, a variant of MVC.
React does not mix business logic and view logic in the same scope.
React does not mix business logic and view logic in the same scope.
> JSX is a templating language.
So is PHP.
So is PHP.
I think proponents of this change are dramatically underestimating how difficult and limiting it will be to maintain seamless interop between two dialects of a language. Interop between languages is hard, and many of the features and changes that you might like to add to a "P++" would make it either expensive or verbose to call or be called by "legacy" PHP. Ultimately I think this could go one of two ways:
A. The "P++" effort ends up hamstrung by the need to maintain seamless interop with "legacy" PHP, and is therefore only able to implement a small subset of the clean-ups and enhancements they envision. It's not clear that this is better than continuing to improve PHP in a backwards-compatible way.
B. Changes to P++ make it so that interop with "legacy" PHP is either very verbose (specifying types, casting, etc.) or incurs a heavy runtime cost. To avoid this, most significant PHP libraries get a P++ clone, and the language effectively forks into two separate communities.
It would be awesome if it's possible to avoid this, but I haven't seen a specific technical proposal for a significantly improved language that maintains seamless interop.
A. The "P++" effort ends up hamstrung by the need to maintain seamless interop with "legacy" PHP, and is therefore only able to implement a small subset of the clean-ups and enhancements they envision. It's not clear that this is better than continuing to improve PHP in a backwards-compatible way.
B. Changes to P++ make it so that interop with "legacy" PHP is either very verbose (specifying types, casting, etc.) or incurs a heavy runtime cost. To avoid this, most significant PHP libraries get a P++ clone, and the language effectively forks into two separate communities.
It would be awesome if it's possible to avoid this, but I haven't seen a specific technical proposal for a significantly improved language that maintains seamless interop.
The same concern definitely crossed my mind as a reader, but I think the coloring of the critique should be less #000000 and more #888888. A lot depends on the technical goals of the "P++" variant - and on the culture among the language maintainers.
* If everyone generally views both language frontends as equal and shared responsibilities with valid technical rationales and only some specific/reasoned differences, then it's probably sustainable.
* If the team becomes polarized, or if one subteam wants to substantially reinvent their language ("Let's make it purely functional too! Bring on the monads!"), then yes... they'll feel hamstrung.
It might be interesting for them to consider comparisons with other systems that support multiple language frontends, e.g.
* GCC supports C and C++ (not to mention C++11, C++14, ad nauseum).
* HHVM support(ed) PHP and Hack
* JVM and CLR both support a range of language frontends.
My guess is that GCC is a more favorable analog (it feels normal+realistic to support C99 alongside C++11 and C++14). JVM/CLR seems like an unfavorable analog (they've supported many very different languages... but involve many large teams and diverse technical specs).
HHVM is probably the most pointed analog. It's just... mixed. On one hand, HHVM succeeded in supporting two similar languages for a long time (in spite of significant idiosyncrasies of PHP). On the other hand, HHVM eventually gave up on PHP and went pure-Hack. But (as an outsider) I'm not really sure the reason. It could be that they got boxed-in on a technical issue of language-interop, or it could be they got boxed-in organizationally (being a separate team maintaining a secondary implementation amid a continuous drip-drip of external changes - not a great position).
I interpret the original link above as basically an assertion (crude paraphrase): "The HHVM folks were broadly right about PHP and Hack and technology and all that; but their implementation hasn't succeeded on organizational grounds, and we-here can do those organizational things better."
* If everyone generally views both language frontends as equal and shared responsibilities with valid technical rationales and only some specific/reasoned differences, then it's probably sustainable.
* If the team becomes polarized, or if one subteam wants to substantially reinvent their language ("Let's make it purely functional too! Bring on the monads!"), then yes... they'll feel hamstrung.
It might be interesting for them to consider comparisons with other systems that support multiple language frontends, e.g.
* GCC supports C and C++ (not to mention C++11, C++14, ad nauseum).
* HHVM support(ed) PHP and Hack
* JVM and CLR both support a range of language frontends.
My guess is that GCC is a more favorable analog (it feels normal+realistic to support C99 alongside C++11 and C++14). JVM/CLR seems like an unfavorable analog (they've supported many very different languages... but involve many large teams and diverse technical specs).
HHVM is probably the most pointed analog. It's just... mixed. On one hand, HHVM succeeded in supporting two similar languages for a long time (in spite of significant idiosyncrasies of PHP). On the other hand, HHVM eventually gave up on PHP and went pure-Hack. But (as an outsider) I'm not really sure the reason. It could be that they got boxed-in on a technical issue of language-interop, or it could be they got boxed-in organizationally (being a separate team maintaining a secondary implementation amid a continuous drip-drip of external changes - not a great position).
I interpret the original link above as basically an assertion (crude paraphrase): "The HHVM folks were broadly right about PHP and Hack and technology and all that; but their implementation hasn't succeeded on organizational grounds, and we-here can do those organizational things better."
By providing PHP-backwards compatibility HHVM, Facebook provided an off-ramp for themselves and other existing PHP users at a time when HHVM was much faster than the PHP interpreter.
But then PHP sped up, and once it became clear that people had stopped using that off-ramp, Facebook demolished it. The off-ramp was infeasible to maintain, and of no benefit to anyone.
But then PHP sped up, and once it became clear that people had stopped using that off-ramp, Facebook demolished it. The off-ramp was infeasible to maintain, and of no benefit to anyone.
Libraries come to mind as a point of concern.
While one do library authors target? Does it split the ecosystem?
As long as one is a subset of the other, this works. If it's a Venn diagram, it hurts.
While one do library authors target? Does it split the ecosystem?
As long as one is a subset of the other, this works. If it's a Venn diagram, it hurts.
It's a little galling that the proposal makes no mention of Hack (https://hacklang.org/), which is also an evolved PHP with static typing that is designed to coexist with PHP 5/7 code on top of a single runtime (HHVM).
Edit: as noted below, since I made this comment, a new section has been added to the doc about this topic.
Edit: as noted below, since I made this comment, a new section has been added to the doc about this topic.
It does make a reference to it further down from the synopsis.
The difference here I think is that most of the PHP community seems to abandon support for Hack, so Hack (as far as I can see. I am happy to be corrected) in the wild is more or less contained to Facebook and its properties. I think a couple of large companies like Slack use it in some places too, but its mainly been disregarded by the broader community (none of the largest frameworks support Hack anymore, for instance).
Which makes sense why Hack is no longer developing with PHP compatibility in mind.
The difference here I think is that most of the PHP community seems to abandon support for Hack, so Hack (as far as I can see. I am happy to be corrected) in the wild is more or less contained to Facebook and its properties. I think a couple of large companies like Slack use it in some places too, but its mainly been disregarded by the broader community (none of the largest frameworks support Hack anymore, for instance).
Which makes sense why Hack is no longer developing with PHP compatibility in mind.
Slack is also a large scale user of Hack:
https://slack.engineering/streamlining-your-workflow-debuggi...
https://slack.engineering/streamlining-your-workflow-debuggi...
Perhaps they updated the file. I see a "This is Hack all over again, isn't it? Why would it fair any better?" section about 3/4 down.
Was Hack a pain to setup? Getting P++ "for free" with PHP 8 seems convenient.
Was Hack a pain to setup? Getting P++ "for free" with PHP 8 seems convenient.
> dynamic, with strong BC bias
> it could be more daring with BC
What is BC?
What is BC?
Backward compatibility in this context.
Thanks. I have used the "backward compatibility" term many times but never abbreviated it nor seen it abbreviated. The only idea that comes into my mind when I see "BC" is "Before Christ" which actually feels pretty much relevant :-)
Indeed they should really have spelled it out first and only used the uncommon abbreviation for subsequent occurrences.
Indeed they should really have spelled it out first and only used the uncommon abbreviation for subsequent occurrences.
I upvoted you, because I had the exact same question, but I also wanted to comment. It seems SOOO common, especially for technical writers, to overuse, or invent, acronyms and to expect that people automatically know what they are talking about. I've been in software for about 20 years, I'm very familiar with the concepts around backwards compatibility, but I have never seen it abbreviated 'BC' before.
If you want to use uncommon acronyms, please be sure to spell it out (e.g. "backwards compatibility (BC)") the first time you mention it.
If you want to use uncommon acronyms, please be sure to spell it out (e.g. "backwards compatibility (BC)") the first time you mention it.
I really struggle to see what the case is for PHP anymore.
I maxed out '04 to '14.
After working in a dozen other languages, the only motivation left seems to be sunk-costs and job-market openings.
It's so domain-specific that you're hamstringing yourself in the future.
That you'd create a new language out of PHP just seems mad.
Who's the audience?
The pragmatic (market) motivations don't exist.
I maxed out '04 to '14.
After working in a dozen other languages, the only motivation left seems to be sunk-costs and job-market openings.
It's so domain-specific that you're hamstringing yourself in the future.
That you'd create a new language out of PHP just seems mad.
Who's the audience?
The pragmatic (market) motivations don't exist.
I agree with this. I'm struggling to get out of my current role/job right now, because I want to move away from PHP (I'm really growing to dislike it as a whole, and in my personal experience have some very negative connotations around the development practices of the PHP developers I deal with on a day in day out basis)
I been looking at C#, what did you find was easy to translate to quickly?
I been looking at C#, what did you find was easy to translate to quickly?
Might seem cliche (?) but Python.
Ignore all the java lipstick that went on after PHP5; PHP doesnt work like a static language and C#/Java really quite different.
Python fits the mental model of PHP far more closely, in that everything you expect to be able to do easily (dynamic dispatch, OO, closures, etc.) are easy. And everything hard (mixins, metaprogramming, etc.) is about as hard.
Most things are easier.
C# may seem more "grown up". From a PHP-culture perspective "Java OO" is grown up, and "procedural C" is babyish. That has more to do with PHP3 vs PHP5 than either Java or C. The latter of which, as with python, includes the best programmers in the world.
From a web job-market perspective I can't say. I got into data science a few years ago, and haven't much contact since. C# may make more sense; it would have back when I was in the area.
Ignore all the java lipstick that went on after PHP5; PHP doesnt work like a static language and C#/Java really quite different.
Python fits the mental model of PHP far more closely, in that everything you expect to be able to do easily (dynamic dispatch, OO, closures, etc.) are easy. And everything hard (mixins, metaprogramming, etc.) is about as hard.
Most things are easier.
C# may seem more "grown up". From a PHP-culture perspective "Java OO" is grown up, and "procedural C" is babyish. That has more to do with PHP3 vs PHP5 than either Java or C. The latter of which, as with python, includes the best programmers in the world.
From a web job-market perspective I can't say. I got into data science a few years ago, and haven't much contact since. C# may make more sense; it would have back when I was in the area.
I actually started with Python, and ended up on PHP because of job changes in the last 2 years (my employer closed their satellite teams so I jumped to a local university. Turns out Drupal is huge in university land, and so PHP. Has not been a stellar experience. I think I had some pre-formed notion that I'd at least be working on more interesting problems, but alas).
I would love to get back to Python, but where I live I mostly see Java/C# job openings (I don't want to live in the Bay Area. My wife has health issues and its complicated to get her care set up again).
and I can't seem to find any places hiring remote Python devs (I did web backends in Python, for reference, not data science. I don't have a CS degree, so I feel timid trying to pushing into Data Science even though I'm a quite knowledgeable Python programmer. I still keep up with all the latest Python news and libraries even).
I'm torn on what to do next. I really would love writing Python full time again. Hell, I'd love to do just front-end web development full time even. I have so much more passion for either than I have writing PHP code. I feel like a glorified Forms creator. Nothing of remote interest is happening in PHP land for me.
When I wrote Python full time we did real-time networking and web back ends. Lots of websocket programming. Async/Await had just taken hold (I came up on Python 3.4 and by the time I was writing it full time we had updated to Python 3.6+). DataClasses was sooo exciting to me. I just miss that energy.
Now with static site generators becoming so vogue I can see all the potential in the world Python has to make the day to day web development experrience so good (IMO, its better at munging data than even gatsby is. Numpy, SciPy, etc. combined with a gatsby-like platform that normalizes all your data into consumable views would be mind blowing)
I know this is a bit of a rant, but I really miss that energy I had when I was living in Python all day. Things just made sense to me. And if I ever had a real performance bottleneck, I could always write a C extension.
Maybe I just need to job hunt better. Unforunately if I can't do C#/Java it needs to be remote work, and I don't feel like I meet the qualifications for any places that hire remote workers. They all want super engineers and I don't really know if I am one :(
I would love to get back to Python, but where I live I mostly see Java/C# job openings (I don't want to live in the Bay Area. My wife has health issues and its complicated to get her care set up again).
and I can't seem to find any places hiring remote Python devs (I did web backends in Python, for reference, not data science. I don't have a CS degree, so I feel timid trying to pushing into Data Science even though I'm a quite knowledgeable Python programmer. I still keep up with all the latest Python news and libraries even).
I'm torn on what to do next. I really would love writing Python full time again. Hell, I'd love to do just front-end web development full time even. I have so much more passion for either than I have writing PHP code. I feel like a glorified Forms creator. Nothing of remote interest is happening in PHP land for me.
When I wrote Python full time we did real-time networking and web back ends. Lots of websocket programming. Async/Await had just taken hold (I came up on Python 3.4 and by the time I was writing it full time we had updated to Python 3.6+). DataClasses was sooo exciting to me. I just miss that energy.
Now with static site generators becoming so vogue I can see all the potential in the world Python has to make the day to day web development experrience so good (IMO, its better at munging data than even gatsby is. Numpy, SciPy, etc. combined with a gatsby-like platform that normalizes all your data into consumable views would be mind blowing)
I know this is a bit of a rant, but I really miss that energy I had when I was living in Python all day. Things just made sense to me. And if I ever had a real performance bottleneck, I could always write a C extension.
Maybe I just need to job hunt better. Unforunately if I can't do C#/Java it needs to be remote work, and I don't feel like I meet the qualifications for any places that hire remote workers. They all want super engineers and I don't really know if I am one :(
For most people, programming language ends up being a very minor contributor to their level of happiness at work. Manager, teammates, and interest in their project (in roughly that order) are the major factors that drive workplace satisfaction.
All that is to say: Probably don't sweat so much over what programming language you use. If the good jobs in your area are C#/Java, then do C#/Java.
> They all want super engineers and I don't really know if I am one :(
The standard is probably far lower than what you're imagining. If you're able to make progress and get things done without consistent supervision, then you're already a "super engineer". Don't be afraid to apply and interview for roles that you're interested in. If you get rejected, 95% of the time it's not because you didn't meet the bar, it's just bad luck (interview loop with incompatible people, too many qualified people applied, etc.) Try not to get discouraged if this happens.
All that is to say: Probably don't sweat so much over what programming language you use. If the good jobs in your area are C#/Java, then do C#/Java.
> They all want super engineers and I don't really know if I am one :(
The standard is probably far lower than what you're imagining. If you're able to make progress and get things done without consistent supervision, then you're already a "super engineer". Don't be afraid to apply and interview for roles that you're interested in. If you get rejected, 95% of the time it's not because you didn't meet the bar, it's just bad luck (interview loop with incompatible people, too many qualified people applied, etc.) Try not to get discouraged if this happens.
Give C# a go. I'm a full-time PHP programmer, and C# has a lot of great things that PHP probably never will.
> Nothing of remote interest is happening in PHP land for me.
Nobody can make you interested in anything you don't want to be, but I'm trying to solve a bunch of non-trivial issues here: https://github.com/vimeo/psalm/issues
> Nothing of remote interest is happening in PHP land for me.
Nobody can make you interested in anything you don't want to be, but I'm trying to solve a bunch of non-trivial issues here: https://github.com/vimeo/psalm/issues
I forgot how many people are on HN of such high caliber. I would be happy to see if I can make any reasonable contribution to pslam.
Not trying to discount your opinion, but it sounds like much of your complaints are related to Drupal more than to PHP. Any job building web forms or hacking on a CMS is going to get old real fast, and those exist in every language used on the web. Work more interesting than building basic CRUD exists in PHP too.
To expand, its not just that. I actually find when I'm working on Drupal I'm at least working fast (its easy stuff for the most part).
I do alot of work for research departments, and that is very boring. Its the same 4 types of form validations over and over, and any attempts I've made to try and abstract over any of it to make the work less repetitive and there by increase productivity, is seen as actively hostile or "in non-alignment with current goals and funding"
Some of my issues is with how things operate where I am, I think, I will admit that.
I do alot of work for research departments, and that is very boring. Its the same 4 types of form validations over and over, and any attempts I've made to try and abstract over any of it to make the work less repetitive and there by increase productivity, is seen as actively hostile or "in non-alignment with current goals and funding"
Some of my issues is with how things operate where I am, I think, I will admit that.
> Some of my issues is with how things operate where I am, I think, I will admit that.
Judging from the previous paragraph, this very much. Initiatives to improve workflows or repetitive tasks being shot down is something I usually just know from big-Corp.
As a side note, if you can't reactor the actual code base to abstract away from what sounds like mostly copy and paste, could you just create a tool that would spit out the form validation code? Pass it form element names, types, constraints and get some delicious code. ;-)
Judging from the previous paragraph, this very much. Initiatives to improve workflows or repetitive tasks being shot down is something I usually just know from big-Corp.
As a side note, if you can't reactor the actual code base to abstract away from what sounds like mostly copy and paste, could you just create a tool that would spit out the form validation code? Pass it form element names, types, constraints and get some delicious code. ;-)
I switched from PERL & ColdFusion to PHP back in 2000 and stuck through every version up to 7 for web app development. I've built apps in both Python and C# (mostly game projects) but never got comfortable with either as a web development language.
It was only when I started working in Go a few years back that I was able to completely walk away from PHP. There is literally nothing I was doing with PHP that I can't do in a more satisfying way with Go and I like compiling everything into a single binary when I'm ready to deploy.
It was only when I started working in Go a few years back that I was able to completely walk away from PHP. There is literally nothing I was doing with PHP that I can't do in a more satisfying way with Go and I like compiling everything into a single binary when I'm ready to deploy.
Back in 2008, I chose PHP for my first forays into web programming because of how easy it was to setup and use compared to other solutions I was aware of. The last time I touched it was back in 2011. Python has pretty much completely replaced PHP for me. Get a good basic web framework like CherryPy or Bottle and couple it with a templating engine like Jinja2 or Mako and you can do anything you could do in PHP, but in a better ecosystem.
Modern PHP is one of the fastest dynamic languages, has one of the best gradual typing systems (IMO almost competitive with TypeScript - TypeScript type system is better at static typing, but doesn't catch runtime errors), and a fantastic community around Laravel/Symphony.
Those are upsides.
For a dynamic language, i'd want:
* A REPL
* A language-browsable std lib or trivial reflection
* A consistent API where expectations are reusable
* eg., polymorphic operators "do the right thing"
* Optional typing
* Typing, when present, facilitates polymorphism
* Data processing handed off to fast VM plugins
* Target of major trans-lang libraries (eg., Spark, et al.)
* Good long-running performance
* Community preference for minimalism and clarity
* Easy package management
* Modern functional primitives (eg., comprehensions)
* Modern OO primitives (eg., extension methods)
* Modern metaprogramming primitivates (eg., reified classes)
And probably others. Each poorly provided feels like taking a big step back; and just an injury to my productivity.
I'm not sure I'd get over how manically procedural PHP is; how sequential by nature. Every OO or functional addition runs against its grain and feels random and accidental.
For a dynamic language, i'd want:
* A REPL
* A language-browsable std lib or trivial reflection
* A consistent API where expectations are reusable
* eg., polymorphic operators "do the right thing"
* Optional typing
* Typing, when present, facilitates polymorphism
* Data processing handed off to fast VM plugins
* Target of major trans-lang libraries (eg., Spark, et al.)
* Good long-running performance
* Community preference for minimalism and clarity
* Easy package management
* Modern functional primitives (eg., comprehensions)
* Modern OO primitives (eg., extension methods)
* Modern metaprogramming primitivates (eg., reified classes)
And probably others. Each poorly provided feels like taking a big step back; and just an injury to my productivity.
I'm not sure I'd get over how manically procedural PHP is; how sequential by nature. Every OO or functional addition runs against its grain and feels random and accidental.
PHP 7+ has most or all of these.
it has a (useless) repl
I think one of the things holding back 'modern' php is the lack of adopting a proper construct for dealing with threads/async operations. Whether its going to be promises/futures, async await operators or what have you, The inability to easily write async PHP hamstrungs it alot.
Its 2019, and I still can't daemonize a PHP process without it leaking memory all over the place.
Its 2019, and I still can't daemonize a PHP process without it leaking memory all over the place.
[deleted]
"I really struggle to see what the case is for PHP anymore."
PHP started as a language for creating dynamic websites and that's still it's forte. I'm not a fan of the language, but it still retains advantages over it close rivals Python and Ruby when it comes to creating dynamic websites. It's faster than those languages, and its popularity means you can find web development libraries for just about anything.
It's also the only language with almost universal support amongst web hosts. It can run on basic shared hosting plans and on nearly every server. It can be deployed by simply uploading your code to a directory on your web host. Many developers (especially of other languages) vastly underestimate how important this is or the opportunities it unlocks.
It's 2019 and if you want a simple [1] way for your non-technical users or customers to self-install your software on a web server, you are simply out of luck.
Having a ridiculously easy web app installation process for servers would unlock countless opportunities for developers to reach more users or customers. But developers simply can't see it.
Isn't it kind-of crazy that web-friendly languages like Python and Ruby are anything but simple if you want to bundle and distribute your web app for easy server deployment?
By the way, here's an excerpt from a blog post by programmer Jeff Attwood:
"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option. If that doesn't scare you, then check your pulse, because you might be dead."
To broaden choice, Attwood argues we should
"build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible."
That was written in 2012 (https://blog.codinghorror.com/the-php-singularity/).
[1] Docker images / Cloudtron / Sandstrom / list of command line instructions - sorry, these don't count as simple.
PHP started as a language for creating dynamic websites and that's still it's forte. I'm not a fan of the language, but it still retains advantages over it close rivals Python and Ruby when it comes to creating dynamic websites. It's faster than those languages, and its popularity means you can find web development libraries for just about anything.
It's also the only language with almost universal support amongst web hosts. It can run on basic shared hosting plans and on nearly every server. It can be deployed by simply uploading your code to a directory on your web host. Many developers (especially of other languages) vastly underestimate how important this is or the opportunities it unlocks.
It's 2019 and if you want a simple [1] way for your non-technical users or customers to self-install your software on a web server, you are simply out of luck.
Having a ridiculously easy web app installation process for servers would unlock countless opportunities for developers to reach more users or customers. But developers simply can't see it.
Isn't it kind-of crazy that web-friendly languages like Python and Ruby are anything but simple if you want to bundle and distribute your web app for easy server deployment?
By the way, here's an excerpt from a blog post by programmer Jeff Attwood:
"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option. If that doesn't scare you, then check your pulse, because you might be dead."
To broaden choice, Attwood argues we should
"build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible."
That was written in 2012 (https://blog.codinghorror.com/the-php-singularity/).
[1] Docker images / Cloudtron / Sandstrom / list of command line instructions - sorry, these don't count as simple.
> It's faster than those languages, and its popularity means you can find web development libraries for just about anything.
In reference to Python:
Faster how? For non-trivial workloads, I have consistently found that pure Python is faster with async/await than PHP
I have not tested django/flask but I imagine that holds up, especially when using gunicorn.
For reference, these benchmarks seem to support my experience: https://github.com/the-benchmarker/web-frameworks
In reference to Python:
Faster how? For non-trivial workloads, I have consistently found that pure Python is faster with async/await than PHP
I have not tested django/flask but I imagine that holds up, especially when using gunicorn.
For reference, these benchmarks seem to support my experience: https://github.com/the-benchmarker/web-frameworks
The first likes PHP roughly the way it is - dynamic, with strong BC bias and emphasis on simplicity
Personally, I have a strong AD bias. Seriously, though, what does this term mean?
Personally, I have a strong AD bias. Seriously, though, what does this term mean?
BC = backwards compatibility
Backward compat - something that's been pretty holy in PHP land for ages and hence got abbreviated in the internals community. Pretty fair IMO to abbreviate something that's so core to a language's vision. Don't forget that HN isn't the target audience of this post: it's people who are involved with PHP internals.
Pretty fair IMO to abbreviate something that's so core to a language's vision.
When talking to the faithful, sure. Language communities need to constantly fight against a tendency towards navel-gazing and only wanting to talk to the faithful.
When talking to the faithful, sure. Language communities need to constantly fight against a tendency towards navel-gazing and only wanting to talk to the faithful.
Come on, this not a blog post. It's a page on the internal dev wiki.
Sure. Maybe I came across harsher than I meant. Please take this in a constructive spirit. I'm a hoary old veteran who has been a part of a non-mainstream dynamic language community which fell under the naval-gazing trap. In the age of the Internet, a language should always be thinking about outreach. It doesn't matter if you have the best technology, or it it's faster and more nimble. The community needs to keep up with the outreach side.
The people who wanted strong static typing have already left PHP. I don't think they're catering to their userbase.
Maybe not their current userbase.
But things are always changing.
But things are always changing.
The PHP base is huge, I've known many good PHP developers who prefer stricter implementations, but work with PHP because they get paid to, and because they know the language and libraries end up using it for new projects. This proposal provides a gradual migration path for those users, and makes adoption a lot more likely.
A lot of people can't easily leave PHP, because they work at companies that use it. Tools like [Psalm](https://psalm.dev), [Phan](https://github.com/phan/phan) and [PHPStan](https://github.com/phpstan/phpstan) have cropped up to help users deal with PHP's slight type system.
I'm very interested in this and will be watching to see where this goes. I've just started PHP this summer as an intern at a company that uses it. At first I was really put off by the language, I had never seriously worked with either web languages or languages that used dynamic typing. So many things seemed strange, dated, or even just plain wrong. On top of that, the official documentation is often confusing as far as best practices go and the ~20 year old comments can only add to confusion (though it is neat when one helps out).
All that said, I've come to enjoy the language for what it is. It works seamlessly with HTML/CSS and can provide so much function with little effort put into configuration. Nearly everything I need to be done can be accomplished without frameworks or libraries, maybe just Bootstrap's CSS to make things pretty enough for the end user.
I could see P++ being useful for PHP as a chance at rebranding. PHP horror stories had made me believe it just had to be bad language. If P++ brings all of the good of PHP along with typing and better syntax in general, I believe it would be a much easier sell to devs in a situation like my own.
All that said, I've come to enjoy the language for what it is. It works seamlessly with HTML/CSS and can provide so much function with little effort put into configuration. Nearly everything I need to be done can be accomplished without frameworks or libraries, maybe just Bootstrap's CSS to make things pretty enough for the end user.
I could see P++ being useful for PHP as a chance at rebranding. PHP horror stories had made me believe it just had to be bad language. If P++ brings all of the good of PHP along with typing and better syntax in general, I believe it would be a much easier sell to devs in a situation like my own.
> At first I was really put off by the language, I had never seriously worked with either web languages or languages that used dynamic typing. So many things seemed strange, dated, or even just plain wrong.
Did you keep a list of these things? That would be really useful to have, because the discussions on the internal mailing list end up saying "We need to talk to users and find out how they found it" and never do...
Did you keep a list of these things? That would be really useful to have, because the discussions on the internal mailing list end up saying "We need to talk to users and find out how they found it" and never do...
No I did not make a formal list, but I probably have some gists from when I started that could jog my memory a bit. Where would be the best place to provide feedback?
If you don't blog, Medium. Or even a detailed gist.
And then share it around - even on the php.internals mailing list if you're feeling brave (but wear a fire-retardant suit when you do)
And then share it around - even on the php.internals mailing list if you're feeling brave (but wear a fire-retardant suit when you do)
There's a long discussion of the FAQ in the internals mailing list: https://externals.io/message/106503
It's important to understand that this is just a proposal from a core PHP developer - at the moment it seems that most other prominent core developers aren't enthusiastic about this particular approach.
It's important to understand that this is just a proposal from a core PHP developer - at the moment it seems that most other prominent core developers aren't enthusiastic about this particular approach.
I don't get the push to add static typing to dynamic languages. If you don't want to use a dynamic language, then use one of the statically typed ones, like Java, Typescript or Go. If it's a case of dynamic languages not scaling well beyond a certain point because of the lack of static typing, then right tool for the job should apply. Don't scale a dynamic language to that size.
Try Typescript and see.
Pushing for static typing in dynamic languages means you can have the best of both worlds.
Example: Any valid js file can also be a valid ts file, but now you can also introduce types, vastly reducing mental load since you always have a polite unpaid pair programmer (the type checker + language server) to help you.
Pushing for static typing in dynamic languages means you can have the best of both worlds.
Example: Any valid js file can also be a valid ts file, but now you can also introduce types, vastly reducing mental load since you always have a polite unpaid pair programmer (the type checker + language server) to help you.
It's mostly from companies with existing codebases built using dynamic languages. Plus everybody's standards for tooling are going up and one of the best ways to improve tooling is through types.
It's the same argument for continuing to manage Excel applications as they scale up to complicated messes.
Rewrite is always a terrible idea. Doing it inside out is an awesome idea.
[deleted]
[deleted]
Sounds like python 3 saga all over again, but in php land.
I disagree, Python 3.x was always meant to be the next version of the language. This seems to intentionally not take that position because the dev team can't settle on which way to go. Python 3.x was difficult to pull off, but it happened, and I actually think it was a bit too conservative with its changes. This would be a parallel language built-in to the same tool.
It'd be kinda like if there was a way to declare your Python code's major version, and then having Python being able to run either.
It'd be kinda like if there was a way to declare your Python code's major version, and then having Python being able to run either.
I see a lot of comments defending PHP with arguments about how fast it is.
They may be right about the PHP7 implementation generally executing faster than most popular Python or Ruby implementations, but they're really missing the point when we're talking about languages and language design, which is what these conversations are really about.
Languages aren't fast or slow, implementations are fast or slow (and all to varying degrees in various contexts).
Implementations are also limited in how much they can impact speed, because the speed of execution is primarily a function of the code, how it's written, and sometimes input size (not how it's executed). In other words, speed improvements derived from implementation optimizations are generally constant-time improvements, not improvements that scale with code complexity or input size.
That means speed of implementation is mostly a concern of certain specific domains where milliseconds really matter. A few of them are HFT, computer graphics, UI rendering, systems programming, etc. Outside of that, code and system design optimizations will be far more fruitful than implementation optimizations.
PHP's design is so intertwined with the HTTP request-response lifecycle that it has been (pretty much) completely and permanently relegated to a very narrowly defined set of use cases, mostly template rendering (or more organized code in the same vein as template rendering, WP, most Laravel projects, etc) and HTTP APIs.
Nearly all PHP use cases involve network latency for every user interaction that makes it past caching layers (to where it's actually executed by the PHP7 interpreter). Allowing network latency to impact user experience for every user interaction (which is practically the only thing PHP knows how to do) isn't acceptable anymore in 2019, and the solution is client-side rendering (JS/V8/webkit/blink/etc). PHP cannot (could not) solve that, because no matter how much you optimize it, it will still take 500ms of network latency to reach the user's browser.
So there's really no use case or domain where PHP is the correct choice if speed of execution is a primary concern, and that would continue to be true even if you made PHP's interpreter run as fast or even faster than V8. The language's design is inherently incompatible with use cases that care about speed, because of how deeply in bed it is with HTTP request-response lifecycle.
What this leaves us with is a language that is only functional in environments and use cases where implementation speed does not matter.
PHP's marriage to HTTP request-response lifecycle has also had the effect of enabling bad coding practices at the interpreter level, because when no process lives longer than a few seconds, a lot of things that should matter just stop mattering. This is why very few people have ever tried to use PHP outside the context of HTTP, and those who have returned with the worst kinds of horror stories.
What that leaves us with is a language that can't even reasonably be called a general-purpose programming language.
And through all the efforts to save PHP from these problems, what are we trying to save? The most inconsistent, cluttered, disorganized and ugly syntax and standard library of any prevalent modern language.
I understand that a lot of people have to work with PHP, that good communities can form and be sustained around that, and that some people can even like it. But if there's going to be any semblance of objectivity in any conversation about language design, it has to be agreed that PHP is a terrible language.
A language that served a great purpose and arguably accelerated the success of the web to a historical degree, but not a language that still needs to be here in 10 years.
They may be right about the PHP7 implementation generally executing faster than most popular Python or Ruby implementations, but they're really missing the point when we're talking about languages and language design, which is what these conversations are really about.
Languages aren't fast or slow, implementations are fast or slow (and all to varying degrees in various contexts).
Implementations are also limited in how much they can impact speed, because the speed of execution is primarily a function of the code, how it's written, and sometimes input size (not how it's executed). In other words, speed improvements derived from implementation optimizations are generally constant-time improvements, not improvements that scale with code complexity or input size.
That means speed of implementation is mostly a concern of certain specific domains where milliseconds really matter. A few of them are HFT, computer graphics, UI rendering, systems programming, etc. Outside of that, code and system design optimizations will be far more fruitful than implementation optimizations.
PHP's design is so intertwined with the HTTP request-response lifecycle that it has been (pretty much) completely and permanently relegated to a very narrowly defined set of use cases, mostly template rendering (or more organized code in the same vein as template rendering, WP, most Laravel projects, etc) and HTTP APIs.
Nearly all PHP use cases involve network latency for every user interaction that makes it past caching layers (to where it's actually executed by the PHP7 interpreter). Allowing network latency to impact user experience for every user interaction (which is practically the only thing PHP knows how to do) isn't acceptable anymore in 2019, and the solution is client-side rendering (JS/V8/webkit/blink/etc). PHP cannot (could not) solve that, because no matter how much you optimize it, it will still take 500ms of network latency to reach the user's browser.
So there's really no use case or domain where PHP is the correct choice if speed of execution is a primary concern, and that would continue to be true even if you made PHP's interpreter run as fast or even faster than V8. The language's design is inherently incompatible with use cases that care about speed, because of how deeply in bed it is with HTTP request-response lifecycle.
What this leaves us with is a language that is only functional in environments and use cases where implementation speed does not matter.
PHP's marriage to HTTP request-response lifecycle has also had the effect of enabling bad coding practices at the interpreter level, because when no process lives longer than a few seconds, a lot of things that should matter just stop mattering. This is why very few people have ever tried to use PHP outside the context of HTTP, and those who have returned with the worst kinds of horror stories.
What that leaves us with is a language that can't even reasonably be called a general-purpose programming language.
And through all the efforts to save PHP from these problems, what are we trying to save? The most inconsistent, cluttered, disorganized and ugly syntax and standard library of any prevalent modern language.
I understand that a lot of people have to work with PHP, that good communities can form and be sustained around that, and that some people can even like it. But if there's going to be any semblance of objectivity in any conversation about language design, it has to be agreed that PHP is a terrible language.
A language that served a great purpose and arguably accelerated the success of the web to a historical degree, but not a language that still needs to be here in 10 years.
> The language's design is inherently incompatible with use cases that care about speed, because of how deeply in bed it is with HTTP request-response lifecycle.
Maybe I'm misunderstanding you, but it sounds like you're saying that speed doesn't matter when responding to HTTP requests. This couldn't be further from the truth. The less time a response takes, the more requests can be handled per second, which is critical for scaling Web services. PHP 7.x handles 2-3 times as many requests per second on the same hardware compared to PHP 5.
Also, I don't agree that PHP is only suitable for responding to network requests. I've also found it ideal for writing CLI programs which can run on a schedule and share logic with HTTP APIs.
Maybe I'm misunderstanding you, but it sounds like you're saying that speed doesn't matter when responding to HTTP requests. This couldn't be further from the truth. The less time a response takes, the more requests can be handled per second, which is critical for scaling Web services. PHP 7.x handles 2-3 times as many requests per second on the same hardware compared to PHP 5.
Also, I don't agree that PHP is only suitable for responding to network requests. I've also found it ideal for writing CLI programs which can run on a schedule and share logic with HTTP APIs.
[deleted]
There's already a statically typed version of PHP, it's called Hack.
Why anyone would use any variation of PHP for a new project in 2019 is simply inconceivable.
Why anyone would use any variation of PHP for a new project in 2019 is simply inconceivable.
Somewhat surprisingly, the main PHP implementation has made huge performance improvements since Hack was released in 2014, and has actually become one of the fastest mainstream scripting languages.
Speed + ubiquity in shared hosting environments + a huge corpus of existing frameworks and code make it pretty attractive for web applications, especially of the CRUD/CMS variety.
Speed + ubiquity in shared hosting environments + a huge corpus of existing frameworks and code make it pretty attractive for web applications, especially of the CRUD/CMS variety.
> shared hosting environments
I see shared hosting and VPS eventually going the way of the dodo now that cloud hosting is mainstream. Has the market seen any growth recently?
I see shared hosting and VPS eventually going the way of the dodo now that cloud hosting is mainstream. Has the market seen any growth recently?
Speed is irrelevant because Hack is compiled.
Shared hosting environments are also irrelevant in 2019.
Shared hosting environments are also irrelevant in 2019.
I love PHP's pragmatism, I love that it's batteries included, and most of all I love the deployment story. It's basically zero-config AWS Lambda without vendor lockin. If they manage to split off a better language without splitting up the community like Python 2/3 or Perl 5/6 did, then that's a spectacular win in my book. Having a little header on top of each file is real nice (and it also opens the door for mixed PHP/P++ projects, another thing Perl and Python failed at).
I find it telling that the PHP community keeps getting this sort of stuff right (they also got the php4->5 migration right back in the days, through collective community action; they fixed the error that was PHP 6 before it was too late, and so on). Pragmatism to the max, things have to not just keep working, but also stay convenient (like Hack wasn't).