6 ms·

PHP's Oddities

• ceejayoz 5mo ago
  Every time I work in another language I miss PHP’s arrays.
  • rokkamokka 5mo ago
    They are an incredibly versatile tool for sure. Even more so wrapped in a Laravel Collection
  • spiderfarmer 5mo ago
    Absolutely. If you don’t know PHP arrays aren’t actually arrays, the other languages feel inferior.
  • bakugo 5mo ago
    For me, it's the exact opposite. Every time I work with PHP, I wish I could have TypeScript's properly typed arrays and dictionaries instead of the janky untyped 2-in-1 mess it actually has.
  • conceptme 5mo ago
    Basically every other language has the same functionality (or better) as a hashmap.
    • ceejayoz 5mo ago
      I’m well aware of them. I’m not sure I agree with “better”.
      • xp84 5mo ago
        I’m very curious to hear your take on this. I started out on PHP for about 4-5 years then moved on to Ruby and JS. I never once had any fond thoughts for PHP’s split-personality array thing. So I’m very curious what it is that other people appreciate about it.
        • ceejayoz 5mo ago
          Having to switch implementations and potentially functionality because, say, the order of the collection matters now is rather annoying, IMO.
  • lazka 5mo ago
    That array keys are auto-coerced to integers has bit me multiple times.
• deleted 5mo ago
  [deleted]
• nasretdinov 5mo ago
  if("0") {} being equivalent to if(false) {} still gives me nightmares even though I've stopped using PHP for at least 6 years now :)
  • kif 5mo ago
    Also `empty("0") === true` is a common gotcha.
  • moritzwarhier 5mo ago
    I knew this in and out, but as a Full-Stack PHP/Symfony/Frontend/JS guy who pivoted to mainly TS for b2b stuff, I still have to occasionally enter !"" into the browser console just to be sure, during code reviews :D
    • tredre3 5mo ago
      In JS/TS: "0" == false : true "" == false : true " " == false : true "1" == false : false !"0" : false !"" : true !" " : false !"1" : false In PHP: "0" == false : true "" == false : true " " == false : true "1" == false : false !"0" : true !"" : true !" " : false !"1" : false Honestly the only way to remain sane in either, but especially if you use both, is to always use === and never use boolean logic (!) when a string could be involved.
      • moritzwarhier 5mo ago
        That's what I say in code reviews as well. Same for numbers. !someValue is useful only for: - booleans, including optional booleans (which is why every bool flag should default to false) - undefined, null (falsy), or object/function (truthy) It's nice for the second variant to also cover falsy NaN or things like this, for example for forms. I guess that's where !!""===false comes from. But it's this exact case that keeps tripping me up. What about empty arrays? Per my original comment, now I'd have to look up if ![] is false in PHP, or just empty([]) === true . So yea I agree, and extend your case to PHP "arrays" (in JS, !![] === true is true
• spiderfarmer 5mo ago
  I think the “bad rep” is coming from developers that stopped developing themselves.
  • frutjgma 5mo ago
    I did PHP for 15 years. Modern PHP looks good but I still wouldn't go back.
    • phplovesong 4mo ago
      What is even "modern php"? It has the same warts than it had back in the day, last i looked nothing is fixed.
  • chuckadams 5mo ago
    I've written PHP off and on since the .php3 extension was a thing, and I can say that PHP very much deserved the bad rap it had for some time. It's evolved beyond most of that, but a lot of that is due to the composer ecosystem making up for it while the behavior of many builtins remains beyond repair. Which is fine, every language has baggage and warts. PHP's warts are sometimes heinously ugly, and they're on full display in many legacy codebases, but modern PHP is something I actually find to be fairly pleasant to develop with, far more than Go or vanilla JavaScript.
    • spiderfarmer 4mo ago
      The most under appreciated thing about PHP is the fact that after 20+ years I can still develop in PHP and never had to learn a JS framework, Rust, Go, Ruby, Java or .NET.
      • fancyswimtime 4mo ago
        ?? you can write JS without having to learn a framework. They exist in PHP too such as Symfony. This constant complaint about frameworks seems less about the framework and more about having to learn to work with people which is partly why the framework abstraction exists.
• mfonda 5mo ago
  After 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 safety with modern static analysis tools. I'm not too sure I agree with the author's complaints here. When using something like array_filter, you're typically mapping from collection to collection (i.e. you don't care about the first element--you care about the whole thing) and so this problem is really a non-issue. The next follow up step would usually be foreach, or another operation like array_map, in which case it's a non-issue. If you really do need the first element, you can use array_first. And if you really do need a fixed-sized collection, you can use SplFixedArray. The point on properties is valid to an extent, but IMO not really an issue you commonly run into in the real world (regardless of language, your constructors should generally return an object in a usable state).
  • shevy-java 5mo ago
    > Modern PHP is great. Many powerful language features, excellent performance, great community and package ecosystem I heard this a long time ago about perl. CPAN is great. Well ... perl entered the fossilized era. I think people do not really observe things correctly. I am noticing the same with ruby right now - everyone sees that ruby is in decline, very strongly so, in the last 3 years. Yet you have blog posts such as "ruby is not dying - it is aging like fine wine". And these are all NOT BASED ON FACTUAL ANALYSIS. I still think ruby is a great language, but if people are not realistic in their assessment of a situation, what does this tell us about people's evaluation in general? People seem to shy away from criticism. You can see this on reddit too, where moderators ban and censor willy-nilly, or even on github, where you can also quickly get eliminated for not conforming to xyz. It's as if some people are very afraid of strong opinions. I don't understand why - an opinion that is objectively false, can be shown to be false.
    • greybeard69 5mo ago
      Mate, not to be rude but your entire comment isn't based on factual analysis; it's a rant about unrelated languages.
• makeitdouble 5mo ago
  To note, it is surprisingly refreshing to completely forgo instanciable classes on a modern codebase. Phpstan deals well with type definitions, arrays are powerful enough to contain whatever needed, and functions can be stored and passed around easily enough.
  • chuckadams 5mo ago
    Array shapes are still second-class citizens defined in phpdoc, with an inferior editor UX, and lack of any run-time enforcement. A proper record type for PHP with value semantics would be an ideal solution for me. Would go nicely with the pattern matching proposal that's still incubating.
    • skydhash 5mo ago
      If there is one thing I love about Clojure and Common Lisp, it’s that you’re not supposed to care about the shape of a complex data if it’s external to the module. What really matters are the functions that are exported and their signature. Anything that’s not standard in the library should be used as an opaque blob. And something like CLOS is about making this easier to define.
• Ayesh 5mo ago
  PHP has quite a lot of oddities such as how loose comparisons (`==`) are made, numeric-strings, and type coercion. But the two oddities mentioned in the article are not that "odd" with a bit of context. - PHP has `SplFixedArray`[^1] that work similar to the standard arrays you expect from other languages. SPL extension is always available in PHP 5.3+, it is not even possible to compile PHP without it anymore. There is no specific type for list-arrays and associative arrays, but there is an `array_is_list` function to quickly check it. - For typed properties, if a property is not typed, it is effectively considered `mixed $var = null`. If the property is typed, and has no default value, then it is considered uninitialized, and not allowed to access. [^1]: https://www.php.net/manual/en/class.splfixedarray.php https://www.php.net/manual/en/class.splfixedarray.php
• bakugo 5mo ago
  > 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 them either in the constructor, immediately after creating an instance, or via some other method that guarantees they'll have a value by the time you need to read them (such as deserialization with validation). If you want your properties to have a default "unset" value that you can trivially check for, that's what null is for. The author doesn't make it clear whether they are aware that you can declare a nullable string and give it the default value of null, but I hope they are.
  • xp84 4mo ago
    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).
    • bakugo 4mo ago
      In theory, that can happen, yes, but in practice, it hasn't been a problem for me. Good third party libraries generally don't leave uninitialized properties laying around for you to trip on, and I find the ability to set non-nullable properties after the constructor to be quite convenient for things like Symfony entities.
• shevy-java 5mo ago
  All of PHP is an oddity. It is a practical oddity, but also ugly to no ends. I am glad to have abandoned it many years ago. Surprisingly enough, I was more productive in PHP than I was in perl. Perhaps perl is even stranger than PHP.
  • acomjean 5mo ago
    Modern PHP is pretty good. I’ve been using it for a while so it’s comfortable. I’ve been doing so Perl maintenance lately and I miss PHP. Perl is a lot weirder than PHP. If I didn’t know C or had dabbled in Perl before I would be completely confused. There is More Than One Way to do it (the Perl rallying cry) causes a lot of confusion. The one nice thing about Perl is that it doesn’t really change anymore, and you can see where it positively influenced others.
• love2read 5mo ago
  I’d love to see a post like this for JS that actually talks about things people run into. Usually when people make a post like this in js, its about archaic things nobody actually uses.
  • dylan604 5mo ago
    https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat Archaic maybe, but still brings a smile
• chuckadams 5mo ago
  > This lax behaviour for property definitions makes writing code around them harder. Especially when you take into account that any object can have properties dynamically added to them: Doing so now raises a deprecation warning, unless you add #[AllowDynamicProperties], and PHP 9 will convert it to an error. I'm told this will simplify internals and unlock optimizations. Arrays are still fairly awful, but generics may become a reality sooner rather than later, and on that could be built Vec and Dict types, à la Hack. PHP is going to be stuck with arrays as they are now for forever, but they'll at least become optional for new code.
  • Yokohiii 4mo ago
    Not sure why a language that barely has a type system needs generics.
    • chuckadams 4mo ago
      PHP has had a type system for over a decade now, including things like union and intersection types that are still not in Java. Most static checking still needs an external analyzer, but even without one, PHP does check subclasses and interface implementations for Liskov substitutability in a way that Python does not.
      • Yokohiii 4mo ago
        I know all that. The issue is that the type system only cares about classes and interfaces. It's all userland abstract types. If a type system doesn't offer safety AND efficiency (i.e. for primitives) I see no value for me. I don't see that happening.
• t1234s 5mo ago
  The last part about "$" is epic.
  • kyriakos 5mo ago
    petition to use Euro symbol when coding PHP in EU.
    • over190bpm 5mo ago
      It reminds me of this great blog post: https://aloneonahill.com/blog/if-php-were-british/ https://aloneonahill.com/blog/if-php-were-british/
    • deleted 4mo ago
      [deleted]
• bwoebi 5mo ago
  Arrays in PHP are mostly confusing if you are used to them in other languages. Instead of $array[0] - the first element is accessed via array_first(). Having them as key-value means, that you can easily just remove some items in the middle, during iteration etc. No automatic shifting happening. The thing which bites me is when some internal functions actually reindex the array. array_filter does not, but for example array_reverse, array_slice etc. do (preserve_keys always defaults to false). And for array_merge too, but there it's no array_merge(preserve_keys: false), but instead the + operator. (Why is this operator overloaded?!) On the topic of the uninitialized state, as co-author of that RFC: I agree with the author that nullable properties should have been auto-initialized to NULL. I haven't ever seen any benefit of an uninitialized state for these. Some co-authors of that RFC disagreed and wished for consistency with the other typed properties. The good thing probably is, that we still could opt to change this with a relatively minor BC break. For non-nullable properties, I do think there is value. Not every value is actually available/ready in a constructor. Sure you can assign dummy values to properties. But it's requiring you to then manually guard/assert that the property is actually initialized. If you happen to access a non-nullable typed property without isset(), then your code is likely broken anyway and I'm grateful for the Error exception thrown. Also, PHP has this peculiar feature of ReflectionClass::newInstanceWithoutConstructor(). This is forcibly having an object in an uninitialized state. Whether that feature should exist or not is a good question, but in practice it's helpful for object hydration for example. This was one further motivation to introduce the uninitialized state. The author of the post suggests checking at the constructor boundary. But this doesn't inhibit objects leaking / not finishing the initialization properly. (class Foo { public stdClass $object; function __construct() { global $foo; $foo = $this; } } new Foo; $foo->object ... is now still existing? PHP doesn't have mechanisms to invalidate objects at a distance. That would be the alternative, but also spooky.) Some choices need to be made, and all choices will have some rough edges. Side note: I personally never use is_null(), but nearly always isset(). This nicely checks for the uninitialized state too. Static analysis tells me anyway, when I access a variable or property name which can never exist.
  • idoubtit 4mo ago
    There's one problem with arrays that I haven't seen mentioned here or by the OP: when inserting a key-value, the type of the key may change. For instance ["4" => "four"] === [4 => "Four"] This can lead to some unexpected behaviors. For example, I've already been bitten by `array_merge()` whose result is different if its parameters are arrays with numeric indexes. array_merge(["4 " => "four"], ["5 " => "five"]) // ["4 " => "four", "5 " => "five"] array_merge(["4" => "four"], ["5" => "five"]) // [0 => "four", 1 => "five"]
• cess11 5mo ago
  I like the arrays, they make it feel like a bit of a low level language and there are some weird tricks one can do with them. As for class property behaviour, I kind of get nervous if my properties or the constructor don't enforce default values I can then fit into downstream logic. One of the best things with PHP is PsySH, or "Tinker" as the laravelists call it. It's not a REPL in the Common Lisp sense, but it is quite nice for an interactive programming shell. I've spent countless hours solving problems very, very quickly in it, and alongside Picolisp pil + and Elixir iex it's one of the earliest tools I install on a new system. https://psysh.org/ https://psysh.org/ The thing I miss the most is a nice concurrency story. It has become better but it's still a bit of a mess, often it's nicest to just implement workers as PHP and then implement control somewhere else, e.g. Elixir, or grab one of the application servers that are nowadays a thing in PHP.
• ryan_glass 5mo ago
  [dead]
• larsnystrom 4mo ago
  I've been writing PHP for 20 years now. It's my bread and butter. The one thing I really wish PHP would add is structurally typed objects. I really miss it when moving back and forth between PHP and TypeScript. They could call them anonymous objects if they want to (that would be a more culturally correct analogue to anonymous classes). Like, I wish it was possible to do { string $mystring = $myvar, } and have it be equivalent to new class($myvar) { public function __construct( readonly public string $mystring, ) {} } and then be able to typehint it like function ({ string $mystring } $myobj) { echo $myobj->mystring; } and honestly, why not go all the way and allow type definitions/aliases, something like type myobj_type = { string $mystring }; That'd be great.
  • idoubtit 4mo ago
    You can do that. Of course, PHP's native types are quite limited, but a phpdoc syntax should work with static analysis tools. For instance: /** @psalm-type MyobjType = object{mystring: string} */ /** * @param MyobjType $myobj */ function (object $myobj): void Here are some documentation and examples: - For Psalm, see https://psalm.dev/docs/annotating_code/type_syntax/utility_types/#type-aliases https://psalm.dev/docs/annotating_code/type_syntax/utility_t... - For PHPstan, see https://phpstan.org/writing-php-code/phpdoc-types https://phpstan.org/writing-php-code/phpdoc-types It may work in your IDE (autocompletion, etc.) but there is no standard on this side. Some IDE have their own parsers, others use one of the LSPs for PHP.
    • larsnystrom 4mo ago
      Yeah, at the moment we use arrays as anonymous objects and phpdoc+phpstan to verify the types, but I want it in the language. PHP already supports intersection and union types, it really feels like just skipping the naming part and going all in on structural typing is not that far fetched by now.
• RobotToaster 4mo ago
  How could you leave out left-associative ternary operators?
  • userbinator 4mo ago
    That's exactly what I was expecting to read about upon seeing the article title. But apparently they deprecated and then changed(?!) the associativity in the past few years, which if anything just makes things even more confusing.
    • moebrowne 4mo ago
      This changed 6 years ago in 8.0, a major version change. Once again showing how out of date peoples hate for PHP is
      • RobotToaster 4mo ago
        To be fair mine and a lot of people's reaction to getting bitten by this was completely avoiding ever using the ternary operator in PHP.
      • guskel 4mo ago
        So it became sane as soon as late 2020.
      • chuckadams 4mo ago
        Ternary was made non-associative in 8.0, so it requires parentheses. It will become right-associative in 9.0. But there’s not much use case left for nested ternaries in PHP since the `match` operator was added in 8.0.
• leeoniya 4mo ago
  surprised not to see http://phpsadness.com/ http://phpsadness.com/ here
  • 9dev 4mo ago
    Maybe that’s because a site last updated 8 years ago is utterly irrelevant for, like, anything?
    • guskel 4mo ago
      It’s not so irrelevant if your org is stuck on older versions of PHP.
      • 9dev 4mo ago
        Being stuck on versions of PHP published >= 8 years ago isn't a valid excuse anymore, with AI and static analysis tools available IMHO. And even if you really don't identify using CVE-ridden, unsupported, ancient software to handle customer data as a critical business risk and insist on riding the burning train instead - well, then you've lost all right to poke fun at the legacy PHP versions you're stuck on, because the pain is entirely self-inflicted by your org.
        • guskel 4mo ago
          I like this guy
• develatio 4mo ago
  I feel like somebody needs to be reminded of “PHP: a fractal of bad design” :D https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
  • McGlockenshire 4mo ago
    That article is approaching 15 years old and no longer reflects reality.
    • develatio 4mo ago
      i think a very big chunk of it is still valid, despite being 15y old
• phplovesong 4mo ago
  PHP is fundamentally broken, and unfixable. Its a toy language, and there is no reason to pick it in 2026
  • reconnecting 4mo ago
    Nice nickname btw.
    • phplovesong 4mo ago
      Thanks!
• chrisandchris 4mo ago
  About undefined vs. NULL: > Not a warning—a FATAL error occurs if you try to access an uninitialized property. This comes up a lot in cases where you try to deserialize data into a PHP object. If a field's data isn't present you might not initialize the property at all. I don't think that is an issue, except in interpretet type-unsafe languages it is harder to anticipate when writing code whether that value is NULL or undefined/uninitialized. E.g. it is basically the same in C#, but here the compiler warns you that the value is not initialized and forbids some actions (like reading the value of it).
• deleted 4mo ago
  [deleted]
• deleted 4mo ago
  [deleted]
• progforlyfe 4mo ago
  I have not seen "PHP" listed as a language used in any Hacker News job posting in a very long time. Everything is Javascript/Typescript now, with the occasional Rust, C/C++, Golang, Python, Ruby. I never see PHP ever.
  • jasongill 4mo ago
    You must not be looking very hard because there's literally six PHP jobs on May's "Who's Hiring" list: https://hnhiring.com/technologies/php https://hnhiring.com/technologies/php
    • progforlyfe 4mo ago
      I count 5 based on that link. And only 2 are in USA, so my apologies, should have said "PHP + allowed to work in USA (remote/hybrid/onsite)". two is greater than zero, so hurray I guess...
• spotlayn 4mo ago
  [flagged]
• flossly 4mo ago
  There's a subreddit dedicated to this. https://www.reddit.com/r/lolphp/top/?t=all https://www.reddit.com/r/lolphp/top/?t=all
• senfiaj 4mo ago
  > 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-about-php 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-javascript https://waspdev.com/articles/2025-04-16/what-i-dislike-in-ja...
  • mpetrovich 4mo ago
    I found php’s array methods lacking as well. The inconsistencies are a pain. I ended up porting many of the methods from lodash, underscore, etc. to php: https://github.com/mpetrovich/dash https://github.com/mpetrovich/dash Maybe you’ll find it helpful
• pavel_lishin 4mo ago
  > 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.
• tacker2000 4mo ago
  [dead]
• tikotus 4mo ago
  I hadn't done any PHP in almost 20 years, not since my studies when LAMP was still the way to go. But recently I had a reason to create a dynamic web page (not what I usually do) and went with PHP. Haven't regretted it. I haven't run into any of the quirks. I keep things simple, and it just works. The only problem I ran into was the realization that PHP is the wrong tool for long running tasks. After some rogue requests/users running my whole service to ground, I had to move the long running endpoints to node.
  • hparadiz 4mo ago
    Try https://reactphp.org/ https://reactphp.org/ for job running. Use apc or memcached for persistent storage. Don't run jobs through web. Queuing things (you can start with a basic rdbma for your queue storage) and have a job runner fire them from a job runner. Can all be done in PHP. Have scaled it to billions per 24 hours.
• nullbio 4mo ago
  The hate PHP gets is from people with 15 year old ideas of what PHP is. It's just bandwagon effect at this point.
  • artyom 4mo ago
    I agree, as I was one of them. Rightfully so, because PHP 20 years ago was the prime example of a complete disaster. Not just occasionally, there were long years of incompatibility, missing implementations, incoherent errors, security issues, fragmentation, etc. Paid my share of dealing with those problems with PHP 5 and 6 (after coming from PHP 4). I think it became a more sane ecosystem around very late 7.x to 8. I won't touch PHP ever again, but I'm glad (no irony) that they finally were able to pull it off. There were some good ideas there, then they quickly became victims of their own success. Nowadays, there's places (Amazon) where PHP is just forbidden at a company-wide level (not joking) because of their early, long-standing reputation of being a mess. Or places where they just gave up and re-implemented their own PHP (Meta). I don't see that changing any time soon.
    • moebrowne 4mo ago
      > Paid my share of dealing with those problems with PHP 5 and 6 Hard to take this seriously when there was no PHP 6. https://ma.ttias.be/php6-missing-version-number/ https://ma.ttias.be/php6-missing-version-number/
      • artyom 4mo ago
        Correct. If you were there, you'd remember the UTF8/Unicode fiasco (how long it took, how many people was both relying and struggling with it, and how they needed to cover it up after even some hosting providers attempted a beta upgrade and had to roll it back). There was a PHP 6 (I'm including the non-updates in PHP 5 "waiting" for it), they just had to rewrite history as of PR damage control back then. That's what the article you linked describes, pretty much.
• iceluc000 4mo ago
  Perfect Circle(neal.fun)
• guskel 4mo ago
  PHP 8.3.6: $ php -r 'var_dump("01234" == "1234");' bool(true) $ php -r 'var_dump("09223372036854775808" == "9223372036854775808");' bool(false)
  • moebrowne 4mo ago
    For anyone wondering the number in the second example isn't just some random big number it's: PHP_INT_MAX + 1
  • stephenr 4mo ago
    If I show a person on the street a Fuji apple and a Honeycrisp and ask if they're approximately the same, they're going to say yes even if they're labeled. Php has had a strict equals operator for decades. You not using it is not a language fault. For the second point: I doubt you'll fine any language where you can just do an equals comparison on floats and it works as expected. That's the nature of floating point numbers.
• FDETalkDotCom 4mo ago
  PHP is bananas kinds of awesome. Yesterday, Cursor coughed up https://fdedictionary.com https://fdedictionary.com for me in PHP. You know what, it is like a dozen files and works awesome, no daemon needed, basically just a web server, some PHP files, and one SQLite file. Today, Claude Code, the major hotness, made changes to a (different) toy app with less complexity, in node.js and you know what, it has ~49,000 files. And uses a 3rd party SaaS to host the db, and another 3rd party SaaS to do auth, and yet another 3rd party SaaS to import a repo and do deployments and hosting. Simplicity has a place for some things. I love PHP+SQLite for tiny apps, and LLMs/agents are awesome at it. I forgot, ChatGPT one-shotted the PHP app and Cursor put the finishing touches on. What a world. Long live PHP, is the point. Arrays and all.
  • sandreas 4mo ago
    For Toy Apps you can even use PHP's integrated WebServer like php -S 0.0.0.0:8000 public/index.php It's not for production use, but only needing one Tool can be helpful under specific circumstances.
    • moebrowne 4mo ago
      Also set PHP_CLI_SERVER_WORKERS=10 to enable multiple threads
• keyle 4mo ago
  Wrote PHP for years. I miss it. Sure it's full of wtfs and as consistent at French on a good day. But as a business language, it's as twisted as the business needs its code to be, I found it to be a great match. And there is literally nothing you can't get Laravel to do. It's that good. Now working with other stacks, most colleagues' features are "wow wow wow slow down this is a big deal" ... In PHP/Laravel, it ain't. PHP is fast enough, powerful enough and comfortingly weird enough. It reminds you that computers weren't that serious.
• usernametaken29 4mo ago
  It was said in different ways in this thread but mostly a language that needs a triple equality operator because they fucked up their normal equality operator to a point where it’s so unintuitive that people flat out recommend not using it at all, is what gives it a bad reputation. Likewise PHP primitives are runtime configuration dependent, you can throw different values at your runtime and get different function returns. I remember large parts of F3 was testing the environment config for databases to see what would be the correct expected returns. That’s insane. I’m saying it. Both of these things make me RUN. I don’t care about features, I can code in C99 if need be. But I can’t deal with a language in which the work befalls on me to read the documentation even for the most trivial things, because it is plainly illogical or not deterministic. That’s why people hate PHP. The rest really doesn’t matter and boils down largely to preference.
• arialdomartini 4mo ago
  Hint: use test assertions instead of print + comments for the examples.
• laurensr 4mo ago
  /joke But it doesn't have Perl's brevity: https://imgur.com/a/CfRqh5X https://imgur.com/a/CfRqh5X