PHP: First Steps

In recent times, I have a chance to collaborate on a major project that powers a major state. It is a great opportunity, because I can see how my skill once again be used in the real world. However, I didn't realize that this was a PHP project. No worry, though. Just another language to pick up.

Working with this language, I came to some impressions of my own.

Some positives:

• I like that this was created to look like C++. So anyone writing in C++ can feel at ease with the language.
• Any change to a php file can be reflected right back. There's no compiling, no reset needed. You just type the same php file into the browser, or F5. And it will run with the new code.

Now on to the negatives. Don't worry, there are plenty:

• I HATE C++. I dabbled in both C and C++. While malloc, pointer-in-pointer are something we all tripped over ourselves, C is something I consider a beautiful language. Easy to grasp, understand, nice syntax. C++ came around with dumb stuff like ::, making it hard to read, which PHP then learned from. Java, annoying as it is to write, uses . instead. I wish kids are taught C instead of Python, or Pascal in my days (close enough to C but useless in real-life). They would understand more of how computer actually runs, data structures, memory management.
• It's hard to debug. Normally when you type echo 'hi', it will print to the browser. What happens when I don't want to print to the browser, then? There is no printf to the console. So later I found out about error_log, which does something akin to printf or console.log on Javascript. So I guess it's bearable. But I have to dig for it. var_dump can be used to dump the entire object, at least that is neat.
• PHP is similar to a scripting language. Not like scripting Python, Javascript. More like bash of Linux, batch of Windows. Each php run, each access is a fresh start. It's stateless, so they have to import classes, library, configuration again. Not like other long-lived languages, frameworks. That's why POST with input value is important, as they have states to give the server.
• Most languages and frameworks I know connect to a database through a series of connections called a pool. These are reusable, so any query doesn't have to re-establish a connection to a database. But since PHP is NOT a long-lived language, it has to do such a thing. So mysqli only has 1 connection. No connection pool so no multi query. It will block if query. Even with MYSQLI_ASYNC. Once you start an async query on a connection, the connection is busy until you call reap_async_query(). So it's NOT EVEN truly asynchronous, because there's no second connection to use unless you make a new one.
• Any long query, you have to make sure there is still response back to the browser, otherwise the HTTP server (those are Apache and Nginx for anyone speaking software) will drop the connection. Here something I do while branstorming ideas on improving a long procedure:

$this->conn->query($sql, MYSQLI_ASYNC);
$allconn = [$this->conn];
$errors = $reject = [];
// Poll the database every 30 seconds
while (!mysqli_poll($allconn, $errors, $reject, 0, 30)) {
	// Print something to prevent timeout
	echo ";";

	// Force PHP to send output immediately, or else if the server holds onto buffer, it timeouts
	if (ob_get_level()) ob_flush();
	flush();

	// Always reset this array, it will be empty once mysqli_poll returns []
	$allconn = [$this->conn];
}

I don't expect this to be completely correct. After all, I thought of this while brainstorming. It didn't work, of course. I couldn't access any other pages of that site, unless I was on another device.
I just wish any long process would just be turned into a worker/background job, with a table to monitor it. So it doesn't hang the entire site like that.

• Someone thought it is good to COPY an entire object in a foreach loop. This is by design. How fun!

foreach ($objs as $obj) {
    $obj.a = 2; // Actual $objs[i].a is still the original value
}

foreach ($objs as &$obj) {
    $obj.a = 2; // Actual $objs[i].a is still now 2
}
var_dump($obj); // Important gotcha with this is that the loop variable is leaked outside the loop scope
// unset the reference afterward!
unset($obj);

There is one more thing I found but unrelated to PHP language as a whole. Someone would write a JSON into a div's attribute and htmlspecialchars it. So they can JSON.parse the element's value. I failed to see the reason behind this move. Just write the JSON normally the first time around would have been better.

Rants over. All in all, unless I use a cheap PHP hosting, like infinityfree.com to write backend or something, I wouldn't be using this language. Python, though slower, is still more maintainable than this language.

To be fair, as I learned from many posts such as this, this, this, most performance issues from a website or web app are database problems (lack of index, lousy queries), questionable design choices for frontend (UI), backend (logic), overloaded Javascript libraries... I like this approach, avoid premature optimization. All this talks about building scalable services, I don't like. What if your service never reaches 1M users? Then you are left with wasted time that could be better spent with more features built.