5 ms·

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

kyriakos 3y ago
It's very unlikely these days for a medium sized and above software project to be written 100% in a single language.
kxrm 3y ago
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.
- trilbyglens 3y ago
  Still do this day I don't know of any serverside language that you can just drop files into to update.
  - quickthrower2 3y ago
    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.
wiseowise 3y ago
If you do it 40 hours a week - absolutely.
dvdkon 3y ago
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?
- mattnewton 3y ago
  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.
  - oaiey 3y ago
    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 ).
    - bawolff 3y ago
      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]
- 9dev 3y ago
  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 :)
agumonkey 3y ago
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.
- oaiey 3y ago
  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)
ludwik 3y ago
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/ 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.

kxrm 3y ago

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.

trilbyglens 3y ago
Still do this day I don't know of any serverside language that you can just drop files into to update.
- quickthrower2 3y ago
  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.

wiseowise 3y ago

If you do it 40 hours a week - absolutely.

dvdkon 3y ago

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?

mattnewton 3y ago
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.
- oaiey 3y ago
  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 ).
  - bawolff 3y ago
    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]
9dev 3y ago
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 :)

agumonkey 3y ago

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.

oaiey 3y ago
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)

ludwik 3y ago

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