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...

Comments URL: https://news.ycombinator.com/item?id=48248630

Points: 2

# Comments: 0

My theory is that AI neural network is trained/formed differently. Humans neural network, which was formed over millions years of evolution, solved survival problems. This also gave humans some side effects, including some types of intuitions. Also humans are much more free, they don't have to obey to a degree AI does, they are able to actively explore / experiment in this world.

AI hasn't that, AI is just fed with tons of selected data and is trained to obey commands. It's neural structure is also different. They are more like aliens taught about our world but at the same time they have to obey us without living in it normally. Like obedient kids who cram to get good grades. This is why AI humor often falls flat because it lacks true emotional intelligence. This is why it's so hard for AI to generate novel things.

This is practical (and necessary) for relatively basic stuff, such as text content, navigation, basic form / input validation, and things like that. But when people write more complicated things (requiring state management, logical branches, etc), like games, 3d programs, etc, it's much more challenging (also can be sub-optimal) and requires more creativity. I mean they are more of a demo art rather than some strong necessity.

I guess it's the whole point of such type of blog posts. Similarly, some people write complicated interactive web pages without using JS, like this https://benjaminaster.com/css-minecraft/. But if you look at the HTML / CSS code size, it's usually huge, but still requires creativity to do that because of constraints. Obviously, it's not something practical or even optimal.

> So not exactly "n" as in O(n).

For large enough inputs the algorithm with better Big O complexity will eventually win (at least in the worst cases). Yes, sometimes it never happens in practice when the constants are too large. But say 100 * n * log(n) will eventually beat 5 * n for large enough n. Some advanced algorithms can use algorithms with worse Big O complexity but smaller constants for small enough sub-problems to improve performance. But it's more like to optimization detail rather than a completely different algorithm.

> This algorithm just uses modern and current processor architecture artifacts to "improve" it on arrays of up to 4096

Yes, that's my point. It's basically "I made binary search for integers X times faster on some specific CPUs". "Beating binary search" is somewhat misleading, it's more like "microptimizing binary search".

Yes, algorithmic complexity is theoretical, it often ignores the real world constants, but they are usually useful when comparing algorithms for larger inputs, unless we are talking about "galactic algorithms" with insanely large constants.

But for a long time (I think even till today despite that there is as an optional free-threaded build) CPython used Global Interpreter Lock (GIL) which paradoxically makes the programs run slower when more threads are used. It's a bad idea to allow to share all the data structure across threads in high level safe programming languages.

JS's solution is much better, it has worker threads with message passing mechanisms (copying data with structuredClone) and shared array buffers (plain integer arrays) with atomic operation support. This is one of the reasons why JavaScript hasn't suffered the performance penalty as much as Python has.

Comments URL: https://news.ycombinator.com/item?id=47874561

Points: 1

# Comments: 0