
P++ idea:  FAQ - tnorthcutt
https://wiki.php.net/pplusplus/faq
======
skrebbel
If they pull this off I just might return to PHP for a lot of work.

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

~~~
72deluxe
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.

~~~
muglug
> 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](https://psalm.dev)),
Phan ([https://github.com/phan/phan](https://github.com/phan/phan)) and
PHPStan
([https://github.com/phpstan/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...](https://medium.com/vimeo-engineering-blog/uncovering-php-bugs-with-
template-a4ca46eb9aeb)

~~~
72deluxe
Thanks for this! This is just what I was looking to know

Thanks!

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

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

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

------
atdt
It's a little galling that the proposal makes no mention of Hack
([https://hacklang.org/](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._

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

~~~
spullara
Slack is also a large scale user of Hack:

[https://slack.engineering/streamlining-your-workflow-
debuggi...](https://slack.engineering/streamlining-your-workflow-debugging-
for-hhvm-effd7db3c72d)

------
qwerty456127
> dynamic, with strong BC bias > it could be more daring with BC

What is BC?

~~~
no_wizard
Backward compatibility in this context.

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

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

~~~
no_wizard
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?

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

~~~
no_wizard
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 :(

~~~
muglug
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](https://github.com/vimeo/psalm/issues)

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

------
stcredzero
_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?

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

~~~
stcredzero
_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.

~~~
skrebbel
Come on, this not a blog post. It's a page on the internal dev wiki.

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

------
maxk42
The people who wanted strong static typing have already left PHP. I don't
think they're catering to their userbase.

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

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

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

~~~
burk96
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?

~~~
porker
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)

------
muglug
There's a long discussion of the FAQ in the internals mailing list:
[https://externals.io/message/106503](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.

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

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

~~~
goatlover
It's the same argument for continuing to manage Excel applications as they
scale up to complicated messes.

------
foobar_
Rewrite is always a terrible idea. Doing it inside out is an awesome idea.

------
xiaodai
Sounds like python 3 saga all over again, but in php land.

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

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

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

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

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

~~~
echelon
> 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?

