Hacker News Reader

> 1. Its variables start with $ and that is ugly:

At the very least it seems nonsensical and cargo-cultish: As a non PHP-er, what is the actual purpose of $? In Perl, it indicates variable context (for better or worse, there's more than one, so it has to be indicated somehow). In shell, it indicates the substitution of variable name by its value. In PHP...I draw a blank. It really seems like an "I wanted my language to look like some other language but I had no idea what it should be doing" kind of thing.

$ was taken from Perl

https://stackoverflow.com/a/3073818

but because early PHP was more simplistic than Perl it only has $.

Powershell also uses $ for variables.

Regardless of etymology of the $ sign and the usefulness of it, personally I like it because it makes it easier for me when I'm reading code, especially if you are scanning fast, to differentiate variables from symbols. Yes, you can get that with your editor too, but for me it is easier to associate the $ sign with a variable rather than a specific color, sometimes you don't have coloring available like when in command line going thru diffs, cat, nano etc.

It seemed kind of obvious to me even at that time that it was taken from Perl. I just didn't get why. PHP could have lifted IMPLEMENTATION DIVISION from COBOL, but likewise, there would have been no point either (fortunately it didn't do that!).

Early web was written in Perl, I guess it was the classic approach of lets borrow what is already successful and in end PHP won over Perl so it worked too. Bill Gates would have been proud.

It's actually slightly wrong to just say "variables start with $". It's more like "$ dereferences a string":

  $foo = "I am foo\n";
  $bar = "foo";
  echo $$bar;

This is in the documentation under "variable variables" [0]. This also lets you create dynamic function names:

  function run_foo() {
      echo "I'm a foo\n";
  }

  $method = 'foo';  
  $picked = "run_$method";
  $picked();

[0] https://www.php.net/manual/en/language.variables.variable.ph...

It differentiates variables from global constant things (constants, class names, function names, ...) for which the scoping is different. So you can have $strlen = strlen(...);

Off the top of my head, I struggle to come up with situations where you'd need an $ to distinguish class names or function names syntactically. Hell, in Lisp I can do (let ((length (length seq-1))) ... (length seq-2) ... ) just fine and it still works as expected, so no special characters necessary either.

Plus, to have different scoping rules was considered a good idea? Weird scoping issues were why I gave up on Ruby fifteen years ago; perhaps it was a good idea that I got never that far with PHP. But I'm intrigued now; what exactly are the scoping differences in question?

TBH, I don't know lisp and I have no clue what you just wrote. Someone new to PHP can just be told $something is how variables look like. And they will recognize variables forever from then on. What's a variable in that lisp code, or in any general lisp code? I have no clue at first glance.

I didn't say it's necessary for the parser, but it's useful for the learner/user.

You can do:

$strlen = 'strlen';

echo $strlen('test');

I’ve also seen things like this:

$return = ...

You can’t use a keyword as a variable in most other languages.

It means the start of a variable name, as simple as that, it isn't anything significant. Maybe it was made to make parsing the language easier at the time, who cares?

You can get used to that in 10 min and move on with your life, it is not a reason to not pick up the language, it's bike shedding.

There was a number of other reasons why I didn't end up using PHP, so it was a bit like death by a thousand cuts. It was not the reason for me, just a small showcase of the weirdness for a newcomer.

> 3. It is trying to be Java: Well, sure it is more like Java, only less verbose and easier to write. Developers can be much more productive in PHP.

I suppose if you are equating extra keystrokes to productivity, then sure. However, Java has vast ecosystems and standard libraries that dwarf most languages. The real gains in productivity are in not re-inventing the wheel for everything. Verbosity has little to do with productivity in the bigger picture.

You are proving my point by defending Java against PHP because my argument was that being more like Java isn't a negative thing.

The productivity point was a secondary point but when it comes to building websites I think people can build faster in PHP although I guess that depends on many factors.

I guess I am not following your argument. Are you not saying that since PHP is less verbose than Java, this is better for productivity? After which you then follow up and say that PHP becoming more like Java is not bad? Seems contradictory, no?

My point was that it was ironic for people to say that PHP becoming more Java-like was a bad thing, but then they said that they prefer Java to PHP.

You are right, I did sneak in there that I find PHP less verbose than Java as an advantage, since most people complain about how much typing you need to do in Java I thought this was worth highlighting.

However personally I think PHP evolving to be more similar to Java was a good thing, even better because imo they copied the good parts, ie: OOP instead of the verbosity but that's up for debate.

In short, becoming more like Java was good, but PHP isn't Java and has its own advantages for web development, imo this is that it is less verbose and easier to write.

I have my reasons to _despise_ hosting PHP from an operational perspective. These mostly come from having to host ready-made PHP applications like Nextcloud, Wordpress, Dokuwiki, etc.

1) 'Language configuration' kept in a php.ini that is usually not shipped with any project. Instead, each project tells you what flags to flip so that it runs, but very often every distribution ships PHP with slightly different flags, effectively making it _very_ hard to have a 100% correct php.ini.

2) 'Deployment configuration' that is additionally present in your FPM/apache configuaration. Again, you have to be told by a project that that these given options (often related to timeouts and request size) have to be set. Many projects just assume you have some 'sane defaults' like things bumped up from the defaults. Again, very difficult to get reproducible deployments of an app, unless the developers are very insistent on documenting everything.

3) Extremely painful to debug. If 1) or 2) are broken and a connection terminates during an upload with some 400 error, the error can be in multiple places: nginx/apache, php-fpm, or the PHP code itself. Each one of them logs to a different place, or not at all. It's difficult to actually understand the _source_ of the error. Good luck. Bring strace.

4) Broken upload model. If I understand correctly, all file uploads in PHP must end up on the local filesystem, and they are impossible to directly stream onto something like S3. This means that my Nextcloud instance will first save a few gigs of data on /tmp, and then only punt it over to S3. Gross.

5) Annoying to host in containerized environments. Both Apache and nginx are the kind of applications that insist on doing a bunch of setuid()s, thereby breaking on hardened containerized environments. Not to mention having to host a nginx+fpm/apache combo per application just seems wasteful, but there's no other easy way to deploy PHP apps in a containerized way that I'm aware of.

6) Configuration woes with rewrites, static files, etc. This is related to 2), in which you have to spend a bunch of time configuring your HTTP server in order to split up requests between static file serving and PHP, set up rewrites, and hope you don't accidentally introduce a security vulnerability.

All in all, compares to something like 'here's a go binary, run it, push HTTP traffic to it, it will serve its own static files, too', PHP is an _extreme_ pain in the ass to host.

You're not being fair to the argument #3. PHP is becoming a less good Java. That's the problem. It's like Java, except it doesn't have generics, doesn't have real data structures (List, HashMap, Deque), no threads or async, no method/function reference or typed function parameters, etc.

So the whole "It's trying to be Java" is more like "What does it offer that's better than Java? Because Java has stuff that is better than PHP."

And I'm saying this as someone who doesn't like Java at all.

> it doesn't have generics

It doesn't need them IMO. It brings no benefit to the language, really. They would need to be type checked at runtime, which can become quite expensive. Static analysis is a better option for an interpreted language. Read this answer from Nikita (one of the top PHP contributors) https://www.reddit.com/r/PHP/comments/j65968/ama_with_the_ph...

> doesn't have real data structures

Untrue. See https://www.php.net/manual/en/book.spl.php It's usefulness is limited though, because it's rare that you need those types of data structures for web applications.

> no threads or async

Untrue. All kinds of projects like Swoole (gives you a runtime similar to Go) and ReactPHP (runtime similar to Node) and https://github.com/krakjoe/parallel for lower level concurrency. There's also pthreads https://www.php.net/manual/en/book.pthreads.php But again most of these aren't necessary for most apps because of PHP's request-response model. Useful for one-off services though.

> typed function parameters

Completely untrue. https://www.php.net/manual/en/functions.arguments.php#functi...

> no method/function reference

You do those like this: [Example::class, 'someFunction']

I hate it when people write such blatantly misinformed comments. Sigh.

> It doesn't need them IMO. It brings no benefit to the language, really. They would need to be type checked at runtime, which can become quite expensive. Static analysis is a better option for an interpreted language. Read this answer from Nikita (one of the top PHP contributors) https://www.reddit.com/r/PHP/comments/j65968/ama_with_the_ph...

Right. You need to use something like Psalm if you want the benefits of generics, which is basically a tacked on type system. Having static checking is absolutely beneficial. I'd be willing to bet good money that you don't write PHP without typehints and/or Psalm/PHPstan.

> Untrue. See https://www.php.net/manual/en/book.spl.php It's usefulness is limited though, because it's rare that you need those types of data structures for web applications.

You're totally right. I was thinking that you still needed to explicitly enable SPL, but that hasn't been true for a long time, IIRC. So, fair enough. I was wrong here.

> Untrue. All kinds of projects like Swoole (gives you a runtime similar to Go) and ReactPHP (runtime similar to Node) and https://github.com/krakjoe/parallel for lower level concurrency. There's also pthreads https://www.php.net/manual/en/book.pthreads.php But again most of these aren't necessary for most apps because of PHP's request-response model. Useful for one-off services though.

pthreads was never worth much. It never worked on web servers and is now deprecated. Parallel is a PECL extension, which may or may not be considered part of PHP, IMO. I believe it also doesn't use threads unless you use pthreads (which you should/can not). So it's just multiple processes- not threads or async. I don't know much about Swoole, etc, but those are frameworks- not PHP itself. Also, I believe Swoole is process based, not thread or (true) async. I could be mistaken. So, again, AFAIK, PHP does not have threads or async.

> Completely untrue. https://www.php.net/manual/en/functions.arguments.php#functi...

That's not what I meant. My wording was poor. I meant specifically `callable`. You can't typehint the inputs and outputs of `callable` parameters. So passing around lambdas, etc, is not robust/safe.

> You do those like this: [Example::class, 'someFunction']

Yeah... an array of two strings. Again, I should've been more clear. I know that's how you refer to functions in PHP. But it's not the same as actually getting to write Example::someFunction and knowing that the inputs/outputs line up with whatever you're doing. If you're lucky, your PHPStorm or whatever can tell where you're trying to refer to a function and maybe point to it for you, but otherwise, it just thinks you're passing some strings around, because you are.

> I'd be willing to bet good money that you don't write PHP without typehints and/or Psalm/PHPstan.

Yeah, think of it like Typescript. Same idea.

> Also, I believe Swoole is process based, not thread or (true) async.

It's a coroutine model, like Go. Very fast. But I don't use it because it's primarily a chinese community, lots of the docs are in broken english. But it's an impressive thing anyways.

IMO, you don't need threading in PHP, there's not really that many situations where it would help during a request-response flow. People generally delegate slow tasks to job queues, which often use https://www.php.net/manual/en/function.pcntl-fork.php to fork off workers. Works great.

> That's not what I meant. My wording was poor. I meant specifically `callable`. You can't typehint the inputs and outputs of `callable` parameters. So passing around lambdas, etc, is not robust/safe.

You can though. `fn(SomeClass $foo) => $foo->doThing()`

> and knowing that the inputs/outputs line up with whatever you're doing

Fair enough, but you can use reflection to look at the callable if you care enough. It rarely matters.

PHP have nice libs as extensions for those data structures. It's std variants that should be avoided.

> It is trying to be Java: Well, sure it is more like Java, only less verbose and easier to write. Developers can be much more productive in PHP

This sounds like kool-aid. Any productivity gain from reduced verbosity would be minimal. Typing out two extra keywords for your method signature is not going to affect your productivity in any real way in reality.

And it being dynamic. If just want to dump some JSON or a CSV into an array to do something with it it is probably going to be much quicker than in Java.

The latest version of PHP that I used was 5.3. The power, and disadvantage, was that it was basically a scripting language which allowed for quick prototyping and easily making some of a site dynamic and allowing for templating. For the more serious/involved/enterprise applications, a lot of workarounds were needed to cache database connections etc.

Lots has improved: ide support, jit, package manager. In doing so it became more mature now joining the realm of more serious, enterprise, languages which had all of this for ages. As such it is also being compared against those languages. At the same time templating is now easier and more cheaply done through static site generators. So imho PHP falls a bit in the middle and it is only kept afloat because of the likes of Magento, Wordpress, and other big products built on top of PHP that thrive by being modifiable by practically any developer.

> I worked with Magento every day and I am glad the language is more than Java than it used to be, it means we can organise our code better

Do you consider Magento being a framework you are happy to work with? I'm also working in Magento 2 and honestly it's a painful experience. It's a so bloated framework that without cache enabled the development is completely awful.

>I won't even entertain this bigotry.

I'm not sure using a word that has historically been used for people who are racist is the right word when talking about programming languages.

You might want to look up the definition of "bigotry" then...

The dictionary definition does not change cultural context.