Hacker News Reader

* duct-tape style of arrays that Just Work(tm) as arrays, hash maps, etc. without having to use any boilerplate code.

It's the main reason why I still prefer PHP for quick&dirty scripting and data processing.

I love PHP "arrays" but there is one tiny gotcha that becomes more important as we do type-safety stuff more and more.

`$a['1'] = 'string';` becomes `$a[1] = 'string';`. This appears to be the case for any fully-fledged decimal number where `(string)(int)$key === $key`

So if you are expecting `array_keys` to return all strings, you might get surprised

Some years ago I was appending underscores to key strings to avoid that. We're talking PHP 5 era. But even at that time stdClass was available. Today, I much prefer either using a stdClass object or actually making a real class when I reach for an associative array. They still have their use cases, though.

I don't think fibers are that great. There's no indication that a function call will create a fiber and do things[1] that might screw with your current state. When you know fibers are around, you need to code more defensively.

[1]: https://withinboredom.info/blog/2022/01/04/thoughts-on-php-f...

> not only integers and floats, but also strings, lists and dictionaries as mutable value types (copy-on-write)

Lists and dictionaries are also mutable in Python. Strings are not. With CoW, are your referring to garbage collection? (value that is no longer assigned to a name will eventually be purged). That would be independent of (im)mutability, so I'm not sure I understand.

With copy-on-write:

    $a = ['a'];
    $b = $a;

$a and $b both point to the exact same bit of memory. Thus passing an array between functions is zero-cost.

When you do:

    $b[] = 'b'; // append 'b'

a new array is allocated, the old data copied to it, and 'b' appended to it (basically, but IIRC, it is a bit more optimized than that).

So basically what FP languages do?

Surprising php has a lot of FP aspects.

It .. really doesn't. (Sure, probably a tiny bit more than Python.)

It's not static types FP like Haskell/Scala (or even TS), as it just recently started gaining some type safety, and while it had map/reduce call_user_func, it wasn't that big in PHP world.

It simply has/had too much mutability for it, and most PHP practice focused on trying to implement OOP ideas in it in a nice way.

FWIW, I don't consider type safety a major issue with FP vs. OOP vs. procedural. I think type safety is just that, a safety net. I've ported things between C#, Scala, and PHP for fun, and regularly find PHP to be more concise due to it's lack of type safety than it being a hinderance. Sure, it sucks that the IDE can't help me out more (lack of generics cough) but static analysis tools really help there, like Psalm and PHPStan. As a side note, Psalm's security scans have pointed out security issues with the original code it was ported from, so that's something...

You can do some pretty fancy things with arrays that you usually only see in FP type languages:

  $arr1 + $arr2 (non-numeric keys) // scala: arr1 ++ arr2
  array_merge($arr1, $arr2) // scala: (arr1 ++ arr2) distinct
  array_unique(array_merge($arr1, $arr2)) // scala: arr1 union arr2
  array_intersect($arr1, $arr2) // scala: arr1 intersect arr2
  array_combine($arr1, $arr2) // scala: arr1 zip arr2
  array_filter(array_map($mapper(...), $arr)) // scala: arr.flatmap(mapper)

in all of these cases, the original array(s) remains untouched. In most OOP languages, the array would probably be mutable (or require some juggling between mutable and immutable types, like C#). That's why its surprising. It's quite verbose in PHP, but the foundations for a FP approach is all there.

What's even more surprising is when performance is comparable to a language like C# on some random benchmarks I've run[1] (opcache + JIT turned on in PHP, C# in "release" optimized compilation). I'd consider it a pretty good contender for serious things.

[1]: https://github.com/withinboredom/distributed-hashmap/blob/23...

Depends on the language. Many FP languages use persistent data structures, sharing some memory with derived/updated values.

Well, what PHP does similarly avoids the risk of accidentally mutating shared values, but it's not the same:

• the value is locally mutable

• no duplication happens when you want to modify it and there is only a single reference

so is object(array,map,etc) in javascript, many scripting languages have non-primitives mutable, the OP seems wrong on this claim(e.g. only PHP does that)

They aren't value types in JavaScript or Python, they're reference types (as are all types in those languages). Mutable value types are different from both mutable reference types (Python list, JS Array, strings in both languages, etc) and immutable reference types (Python and JS strings, Python tuples…)

Pretty sure they meant immutable in that quote.

No, I didn't! PHP's string and array types are neither immutable nor a reference type. In this way they are very different from what Python, JavaScript etc do.

> a standard library that doesn't require import statements

I consider this a non-feature in JS. The global namespace is enormous and growing rapidly. As I recall, PHP’s global namespace is similarly enormous (and notorious for its inconsistencies and redundancies). I understand that there are ergonomic advantages to not having to import built-ins, but I think framing it as a feature deserves a healthy asterisk :)

> fibers, a way do asynchronous execution without every function in the callstack having to be aware of it

This isn’t built into JS, but there’s an implementation of it, mostly used and popularized by Meteor. Again it has some ergonomic benefits, but I think it can too easily hide/obscure deoptimizations—eg performing IO operations in sequence which would be better performed concurrently.

well, PHP does have proper namespace support so you can easily avoid collisions. although I don't really think it's that much of a problem either way

I think JavaScript global namespace is massive in the browser. Under nodejs things are much saner.

It’s increasingly almost the same, aside from very DOM/*ML rendering contexts, and getting more similar as time goes on. Which is good for portability but JS (ECMAScript/TC-39) is huge in itself, and the various compatible things in the JS runtime ecosystem (browsers/Node/Deno) is also huge. Node was historically more limited here but given how much the language itself is expanding they have to choose compat.