Earlier quoted context omitted.
An “array” in PHP is an ordered map.
Isn't exactly their complaint? It's called an array, referred to consistently everywhere as an array, but it just ... isn't.
Better than calling it a hash.
PHP's Oddities
91–100 of 186 posts
Re: PHP's Oddities
#92> This example exposes the "uninitialized" state that a property can be in, which is NOT the same as NULL. This distinction frustratingly comes up when you try to do a null check on these properties: If you're accessing an uninitialized property or checking if a property is uninitialized, you're probably already doing something wrong. The point of class properties with no default value is that you're supposed to set…
I think anyone would agree with the “you’re doing something wrong” part, but if you declare that a property is typed and non-nullable, it would be nice if a constructor that didn’t populate its non-nullable properties would cause an exception to be thrown or something, as the constructor didn’t construct a valid object by its own specification. The wrongdoing was in the constructor so the constructor should be where that happens, not the innocent caller later who trusts the type definition.
Maybe it’s too impossible to do that, but the behavior described seems like it puts you right back in the world of completely dynamic anything-goes (PHP’s legacy, basically).
I thought part of the point of types was to give the caller confidence that simply accessing a typed property is guaranteed to return a certain type (null being a type that may be included).
Re: PHP's Oddities
#93[flagged]
Re: PHP's Oddities
#94PHP is fundamentally broken, and unfixable. Its a toy language, and there is no reason to pick it in 2026
Nice nickname btw.
Re: PHP's Oddities
#95Earlier quoted context omitted.
Php has compile time safety too but compile time occurs at roughly the same time as runtime lol
I'm not familiar with PHP, can you elaborate on what you mean here? What is it compiling? Or are you referring to type safety?
When a php file is loaded at runtime, it runs through a very basic JIT compiler that does statically check a few things before continuing with execution. Syntax, for example, is checked for the entire file during this step.
Most type checking happens at runtime (this might not be true for interfaces at some level, but I can’t say for 100% certain - I just know I tend to see interface related errors earlier during code execution…). It’s perfectly valid syntax to declare a private method as returning an integer and then for the body of the method to return a string (explicitly cast as a string even). As long as you never call that method at runtime, no exceptions will be thrown.
With a half decent IDE or LSP, these sorts of runtime exceptions can be easily avoided but technically they still exist and if you don’t know about that, it can be argued to be confusing. PHP has made a lot of trade-offs to largely maintain backwards compatibility and many of them live in decisions that happen at runtime.
Modern PHP tooling can provide type safety in a very similar way to Typescript if you’re willing to put in the effort while also still technically offering you an escape hatch to do whatever the heck you want and duck type to your hearts content.
Re: PHP's Oddities
#96There's a subreddit dedicated to this.
Re: PHP's Oddities
#97After over two decades of working in PHP, I'm now working in Java. PHP is basically Java-lite. I am absolutely loving the compile-time safety of Java, but I dearly miss PHP's maps and arrays. In Java, the amount of verbosity for defining a map/list and operating on it is overwhelming. Modern PHP is great. Many powerful language features, excellent performance, great community and package ecosystem, and decent enough…
Have you tried Kotlin? It's a less clunky Java. The syntax is IMHO Ruby-level charming (for an OO-first lang), but with types that are quite a bit stronger than Java. Java interop is quite smooth.
Re: PHP's Oddities
#98> Despite all the critiquing I've done in this article, I still think the amount of hate PHP gets is undeserved.
As a person who also codes in PHP at work, I still dislike the language syntax part. JS/TS also has terrible parts, but IMHO, compared to PHP, I don't face them as much and they are much easier to avoid when you have enough knowledge and stick to good parts.
As the author mentioned, in my experience PHPs arrays are quite annoying to work with, and you can't do anything about them. This C-like procedural syntax for array and string manipulations makes discoverability harder. Some functions (in_array, implode, shuffle, trim, stripos, lcfirst, etc) still have inconsistent namings despite many of them have a standard prefix in their name, such as array_ or str_.
I mean OK, PHP is still widely used, has new features and is still and far from dying (mostly for reasons other than syntax), but please don't pretend that it hasn't some issues with basic stuff which are still there even in 8.x version.
Just to not write a full article, you can read here: https://waspdev.com/articles/2025-06-12/my-honest-opinion-ab...
If interested, I also listed some annoyances of JS: https://waspdev.com/articles/2025-04-16/what-i-dislike-in-ja...
Re: PHP's Oddities
#99Earlier quoted context omitted.
Isn't exactly their complaint? It's called an array, referred to consistently everywhere as an array, but it just ... isn't.
Better than calling it a hash.
I don't think it is, tbh.
Perl's hashes are a complete mystery to me still, but at least it lets me know that it's not just a linear, uh, well, array.
Re: PHP's Oddities
#100> You just have to know that, or else you end up with subtle bugs.
This might as well be PHP's slogan, tbh.
I've worked with PHP since... good lord, 200...2? And it's wild that this is still the case.