Hacker News Reader

Comment by cloudking | Hacker News Reader

At the end of the day if your software works and users like it, does the programming language even matter?

It does, language comes with culture, I'm polyglot and the amount of horrors I've seen in php3/4 days was on par with legacy cobol.

It was too sweet on effectful code around random maps (what's not to like, you can do whatever and spend hours trying to find the right combination of stdlib array_ functions until something happens).

Of course things change after the nonphp6. But if someone only knows and love php I'll check twice before working with him. I'm actually dealing with someone like that right now.

Yeah, the "culture" had its technical issues. But in real culture PHP people are typically good mooded, friendly and humble fellows.

So culture is a plus thing. Because the technical mishaps are there in any community with size (looking at you JavaScript)

It does matter. I can't offer an opinion on the modern state of PHP since I'm not familiar with its recent developments. However, it's true that certain programming languages and frameworks can facilitate writing maintainable, secure code, while others might naturally foster problematic, insecure code. It isn't to say that you can't write good code with them, but it can be unreasonably difficult.

Take, for instance, the PHP environment around the time the "a fractal of bad design" (https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/) article was published — which also coincides with the last time I worked professionally with PHP. During that period, PHP was plagued with inconsistencies, a tendency to hide errors, and insecure default settings, all of which encouraged writing bad, unmaintainable, and insecure code. Those aspects truly matter.

It's very unlikely these days for a medium sized and above software project to be written 100% in a single language.

I agree that it should not matter but there are people out there who really have strong feelings about PHP. I understand those strong feelings because PHP was very popular since it was on every shared host and it was super easy to quickly whip up scripts that render dynamic pages back in the day. That ease had consequences that PHP is trying to dig out from under to this day. I personally reach for PHP first for all my personal web projects. It's where I am most comfortable.

I write C++, Rust, Python, C#, and JS in various capacities both personally and professionally and I always go to the first language I learned whenever I want to prototype, PHP.

That said, I agree with the sentiment you are expressing. If the app works, and people enjoy using it, the underlying language only matters to other devs who might work on it and that is it.

Still do this day I don't know of any serverside language that you can just drop files into to update.

Next.js is a bit like this. In at least it does the 1-1 file to route mapping. Not drop in on the server but is so on the dev machine.

Maybe not for the user, at least not directly, but developer experience is something to optimise for.

PHP is also the one language whose choice can make an impact on users' experience, since its shared-nothing (sans caches) runtime model is almost CGI-like and can, in my experience, lead to higher latency, as each request simply does more. Maybe some experienced PHP devs can tell me how they combat this?

The most common defense I hear here is that the inefficiency just never mattered.. and if it did it was because the product was a blockbuster success and you could hire to rewrite the slow parts or adopt hack or whatever.

It does not when your project has not 100s of users hitting at the same time. And honestly, which application survives that at first sight and does not need to solve the problem one level higher (like building for load balancing, writer/read databases, etc ).

I mean, generally what matters is how things scale. This type of slowness is trivially solved with horizontal scaling. Not just that, as a design choice, shared-nothing makes horizontal scaling easier. So this type of slowness isn't really the type that matters, and if anything is actually a net benefit at scale. [Unless you are truly latency-critical, but quite frankly that is pretty rare and php would probably not be the best choice for that at any scale]

There are multiple options by now. For one, PHP got a JIT compiler a while ago. That, in combination with the existing opcode cache, actually causes PHP to outperform its interpreted competitors in most cases.

Additionally, there are several application server strategies, sometimes with a process manager that keeps preloaded request workers at hand, sometimes hosting an event loop, and sometimes a request worker that gets partially reset after handling requests. This yields performance comfortably comparable to optimized Node.js apps.

In general, PHP has a highly optimized runtime, and we didn’t even really touch caching yet. Trust me when I say performance is not one of the problems PHP poses :)

And not to forget traditional web server caching. Since they mimick html files on the server, doing your app right, you can use the very mature caching options in the web server / proxies.

If you need it, Swoole and Roadrunner exist

> since its shared-nothing (sans caches) runtime model is almost CGI-like and can, in my experience, lead to higher latency, as each request simply does more. Maybe some experienced PHP devs can tell me how they combat this?

I mean, you kind of answered your own question - they use caches like apcu or memcached. Apcu is just shared memory so its basically ends up being very similar to languages that don't do shared nothing.

If you do it 40 hours a week - absolutely.

Reply on news.ycombinator.com