
Good thing in PHP nobody talks about - jetter
http://pixeljets.com/blog/good-thing-in-php-nobody-talks-about/
======
mgkimsal
The phrase "shared nothing" springs to mind.

Years ago (1999?) one of the early PHP bloggers had written that PHP was good
precisely because of 'shared nothing' architecture. There was no shared
memory, no threads, etc to trip you up.

Years ago, and colleague bitched about PHP, and one of the issues was 'no
thread support'. I went to pick him up for lunch one day, but he couldn't make
it - 'debugging some threading issues' (in either java or c++ - can't remember
which one). I... didn't quite bite my tongue, and, while I know 'different
tools for different jobs' makes a lot of sense, I also know many people have
made more work for themselves by explicitly avoiding even greenfield projects
in PHP because... well.. because it's PHP.

Also, from what I gather, PHP will be getting real async support in a couple
years, which may throw some of the 'ease of thinking' arguments out the window
a bit.

~~~
madaxe_again
There has been threading in PHP via the pcntl_ functions for a long while -
since PHP4.

You have to have some pretty exotic needs to want to use them, but threading
does exist, and I’ve built a multithreaded php app using it.

~~~
gnarcoregrizz
The needs aren't very exotic. You can use them any time you need to do
multiprocessing, a common example is building a daemon to process a queue in
parallel with multiple workers.

Also, the pcntl functions don't provide multithreading primitives, only
multiprocessing (fork)

Edit, looks like there is also a pthreads extension

~~~
Shish2k
> The needs aren't very exotic [...] a common example is building a daemon

While "writing a daemon" is pretty common, I've never seen a daemon written in
PHP (I'm sure they exist, I've just never seen one), so I would call that an
exotic use-case :P

~~~
aequitas
I had to maintain one, would not recommend it as a general pattern. Most of
the problems might as easy have to do with the original author and his
experience in writing such an application (and hence choice of PHP for this
task). But this post also springs to mind: [https://software-
gunslinger.tumblr.com/post/47131406821/php-...](https://software-
gunslinger.tumblr.com/post/47131406821/php-is-meant-to-die)

------
rll
It was definitely intentional. The prefect sandbox has been a central design
decision since day one.

~~~
mirashii
Citation needed.

The reality is almost certainly far simpler. PHP started as a suite of tools
for writing CGI pages [1], which have the same property mentioned. As with
many things, that early design choice has followed through and led to
continuing to execute PHP in similar ways as CGI did way back then.

[1]
[http://php.net/manual/en/history.php.php](http://php.net/manual/en/history.php.php)

~~~
mgkimsal
> Citation needed.

I think the 'rll' user is Rasmus, who started PHP. I think he would be the
best person to cite re: intentionality.

~~~
Walkman
This is why I read HN every single day. This comment is epic :D

------
ibudiallo
I have been working on .Net c# this past 2 years, coming from PHP. The hardest
thing for me was to remember to close my database connections. Of course when
you don't close one connection, your app doesn't break, it simply consumes
more memory. After a few hundred requests, your database fail and you have no
clue what went wrong. (close your connections!)

In PHP, when your page is done processing, the process is killed and all the
connections, file handles, or resources it had open will be closed.

The more I work with .Net, the more I get to appreciate the things in PHP I
had taken for granted.

I wrote about this a year ago: [https://idiallo.com/blog/php-fast-debug-
time](https://idiallo.com/blog/php-fast-debug-time)

------
throwawayjava
Presumably, this guy's never seen $_SESSION hell: enormous amounts of state
stashed in a single super-global associative array that persists between
sessions [1].

In addition to $_SESSION hell, lots of custom PHP applications end up with
extremely complex and convoluted MySQL tables dedicated to storing what would
typically be global application state.

Both of these can lead to difficult-to-debug performance issues, race
conditions, and especially security vulnerabilities.

Global state is going to happen, so languages/libraries should provide
mechanisms that make it easy to state and enforce strict invariants on reads
and writes to global state.

[1]
[http://php.net/manual/en/reserved.variables.session.php](http://php.net/manual/en/reserved.variables.session.php)

~~~
fgheorghe
Thats pretty much a bad practice well documented accross various php tutorials
and books. But many php developers have no understanding of programming so
they stash everything in that _SESSION superglobal or do other scary things.

~~~
throwawayjava
Global state _in general_ is bad practice well documented across tutorials and
books about programming. Article's argument is that PHP avoids global state,
but _SESSION hell and "MySQL table as global state" patterns demonstrate that
programmers will always find a way to shoot themselves in the foot with global
state :)

Also, IME even good PHP programmers suffer from the "MySQL-table-as-global-
runtime-state" syndrome. And it's at least as bug-prone as storing global
state in an ADT.

------
attrezzarturo
Anything, in any language can be written to not share state, to reload
everything on every request and to throw out after the response.

We're setting the bar pretty low for what's a good thing in a language here.

~~~
Joeri
But practically speaking you can’t though. You’re not starting a new java
process on every request because the overhead is too big, and you can’t fully
reset the jvm state for every request.

PHP with fastcgi reliably and quickly resets the php process to freshly
launched state after every request, and very few languages can manage that
trick in a production context.

~~~
attrezzarturo
Practically speaking it's done a lot. Even outside of web development.

For example Gradle (a java build system) runs a daemon that hosts a bunch of
tasks that run and die.

Docker does it with images.

The browser does it with tabs.

Php achieves it with the help of server components. That is fine, but I
wouldn't advertise it as a feature.

~~~
jamespo
Starting a new docker instance for each http request is an interesting
approach

------
lolc
Yes PHP, that's how it all started with CGI. This provenance also dictates
that PHP must be fast to load. I'm often surprised at how fast a PHP process
will complete in comparison to Python.

Still, I remember having to cache initialization state in PHP because it took
too long to build it on every request. That's when the model breaks down and
you prefer a server with state.

~~~
throwawayjava
_> Still, I remember having to cache initialization state in PHP because it
took too long to build it on every request. That's when the model breaks down
and you prefer a server with state._

I also had this problem, but fortunately, I could always buy my way out of the
problem better hardware and maybe one afternoon of optimization.

I finally shut down the last of my PHP side projects because of pervasive
security issues and a dwindling/dead community. I recently reinstalled one of
those sites on a DO droplet. Getting the right versions of everything took an
entire weekend, but I eventually succeeded. The droplet had way more RAM and a
faster CPU than I had access to back in the day.

But _holy hell_ those pages still loaded _so_ slowly. I probably didn't notice
at the time because internet connections were so much slower and waiting for
an HTTP page with a few images to load was normal. But those load times would
be absolutely unacceptable today.

------
meritt
Guilty admission time: I run thousands of distributed worker processes in PHP.
Some of the processes run for months at a time and I've not encountered any
issues nor memory leaks. I assume the others would too but they get replaced
anytime we deploy, so the uptime is usually measured in days.

~~~
mgkimsal
how long have you done this?

Years ago (2005? 2006?) I had a lot of trouble running PHP processes for any
serious length of time, but don't now (7.1 mostly)

~~~
meritt
We've been doing it since 2011, though we saw _significant_ improvements when
we switched to 7.x. Memory and CPU usage dropped by ~50% at that time. We did
have occasionally memory leaks back on 5.6 (usually around shared libraries
like libxml) but haven't had any issues whatsoever since 7.

I didn't try too much daemonization around ~2005, though Schlossnagle's
"Advanced PHP Programming" (2004) did have a whole chapter on daemonizing and
the pcntl functions that made it possible.

------
GranPC
Isn't this the case for any programming language if you run it through CGI?

~~~
noncoml
How does it work for websockets? Do you have to spawn one process per
connection?

~~~
judge2020
Yep, which is why Laravel [0], CakePHP [1], etc prefer to use a node app or
separate server to handle WebSocket connections that then use an internal
router to call PHP code.

0: [https://laravel.com/docs/5.6/broadcasting#driver-
prerequisit...](https://laravel.com/docs/5.6/broadcasting#driver-
prerequisites)

1: [https://github.com/scherersoftware/cake-
websocket](https://github.com/scherersoftware/cake-websocket)

------
stunt
Developers just blame programming languages. As always.

As much as a programming language gets more popular, and more programmers
write code with it, you see more "quick-and-dirty" solutions around.

As Java started to become even more popular cos of Android, I see more crappy
code written in Java.

As much as Scala codes were clean when only early adapters would pick it, now
I see more "quick-and-dirty" code because simply there are more codes out
there.

The main problem is the majority of developers are not
disciplined/experienced/responsible enough to keep their code organized and
learn how to do it.

And that is just how it works with everything we do. Majority of people also
don't keep their house/room/desk clean and organized.

As soon as any programming language hit the top 5 popular programming
language, you have enough example to complain about it.

------
k__
Funny thing how we go full circle with FaaS now, lol.

------
tambourine_man
There are a lot of nice things in PHP. The bad parts are pretty well known.

As Bjarne Stroustrup said, there are only two kinds of languages: the ones
people complain about and the ones nobody uses. Having invented C++, he should
know.

------
rqs
> ... at the same time the single and the only huge factor which make poor PHP
> code written by junior developers manageable is this ...

One thing many people misunderstood is that "PHP are for newbies".

No, you need to have some serious knowledge on PHP to be able to navigate
yourself away from all those pitfalls that language provided. For example, use
===, be careful with "0e123" etc.

All those pitfalls combine, is annoying enough to out weight most the good
things that PHP also provide.

------
codedokode
PHP being stateless is a good thing, as well as real classes, real interfaces
and type hinting.

Sadly, PHP developers still use bad coding practices. For example, one of the
popular PHP OOP frameworks, Symfony, makes things like HTTP Request or logged
user a global variable by storing it in DI container. What about incapsulation
and concern separation? The code breaks if you run it from CLI. PHP should not
copy bad ideas like this from Ruby.

------
deweller
The good thing in PHP that I don't think enough people talk about is Laravel.

If you are starting a new PHP web app and you expect to grow beyond a toy
project, I highly recommend starting by using the Laravel framework. Laravel
provides so many useful things and it encourages good separation of concerns
and code organization. But it is flexible enough to get out of your way if you
need it to.

~~~
codedokode
I don't think Laravel is a good example. It uses a lot of global state and
static method calls. It copied all bad things that were there in Ruby on
Rails.

If you look at any code example here [1] you will see that global variables
are used everywhere.

[1] [https://laravel.com/docs/5.6/urls](https://laravel.com/docs/5.6/urls)

~~~
deweller
Using global variables in a careless fashion is a bad practice indeed.

But globals are not universally evil. Laravel uses globals very thoughtfully.
Having used the Laravel framework for many years, I agree with many of the
choices it has made.

Additionally, Laravel does not force you to use Globals. See
[https://laravel.com/docs/5.6/requests](https://laravel.com/docs/5.6/requests)
to dig a little deeper.

------
emodendroket
I find PHP better than I thought I would because it supports a style of
programming that's very similar to Java, but the big problem is that PHP
developers often tend to have more of a "quick-and-dirty" mindset and don't
really appreciate that kind of code.

~~~
drivingmenuts
As a PHP programmer, among other things, I think Perl programmers have the
ultimate "quick and dirty" mindset, but they're typically trying to solve
different problems from a different perspective.

I also think a lot of the bitching about PHP is mostly because newer
programmers are just repeating what they heard with the fervor of someone who
doesn't work in PHP regularly.

Does it have problems? OH HELL YES. So does every language. Are the problems
ever going to be fixed? OH HELL MAYBE. Is it the perfect hammer for every
nail? OH HELL NO.

I work with what I know and I live with the problems because that's what I
know. If I need new features, I'll work in another language, maybe.

No language is without issues. Except Python. Python is perfect.

~~~
exceptione
Python is surely nice looking, but as it allows redefinition of everything at
runtime, it is impossible to optimize at compile time. I think PHP, with the
recent type strictness functionality, is better positioned for making way to
new developments like meaningfull code analysis, (compile time) optimizations
and performant JIT compilers. Python is too dynamic for that, unfortunately.
The same holds for JavaScript.

~~~
emodendroket
PhpStorm with the Symfony plugin is already excellent for code analysis if
you're working in Symfony

