4 ms·

I find the virtues quite uncompelling, take for example >First, state. Every web request starts from a completely blank slate. Except for, you know, when you

by Tehnix 10y ago

I find the virtues quite uncompelling, take for example >First, state. Every web request starts from a completely blank slate. Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run once. >I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. Over the course of a long and complex software project’s life cycle, these productivity gains compound. I cannot disagree enough with the conclusion he draws from the quick feedback loop in PHP. I do PHP in my day job, because that's what our codebase is in, but recently I finally got the opportunity to use Haskell for a side project. The feedback-loop might be slower (honestly not by much, automatic reloading is a thing in almost any framework), but I'm a zillion times more confident in my code, because you are able to encode so much logic in the type system, meaning the compiler will catch whatever. Contrast this with PHP, where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours. Particularly when refactoring code, which you often end up doing while hasing something out. Also, PHP works at a quite coarse granularity of concurrency. A thread per web request only? As soon as you want to do something more advanced, you are forced out into the many patchwork solutions (wanna do async? queue that shit). Sure, a lot of people have done a lot of quite cool projects in PHP, but I would much more benefit that to the lower barrier to entry - heck PHP was my first language and I made a CMS from scratch without even knowing much of what I was doing. That said, it has come a long way, and something like HHVM/Hack definitely helps a bunch! I just think the pros in this blog post are quite weird and IMHO incorrect. </rant>

bkanber 10y ago
> Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run once. I mean, you're not reinitializing it, and it's not exactly slow. And when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere. > where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours I'm not really sure what you mean by that. Write a method, write tests for that method. Just because PHP has weird type coercion issues doesn't mean you can't be diligent about the types that you use. And of course tools like PhpStorm understand docblocks, annotations and PHP types and classes and basically does the same thing that a compiler does, it'll show you big honking type errors if you ask it to, it'll even stop you from committing broken code if you use that option. > Sure, a lot of people have done a lot of quite cool projects in PHP, but I would much more benefit that to the lower barrier to entry I don't know about that. Low barrier to entry gets you a lot of crummy projects. In my experience PHP is a lot easier to manage and maintain in production, and that's a huge advantage to companies and products with small teams.
- Tehnix 10y ago
  >when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere It's just as easy to scale with other languages, you would keep the data that needs to be persisted in a DB. The benefit comes from things that does not need to be persisted, like resource pooling, memoization, config loading etc. > > where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours >Write a method, write tests for that method Exactly, I need to write tests for things that are trivially verifiable by a compiler. And I'm not just talking about type coercion (which is a bad thing), but also missing function parameters, wrong parameters, missing initialization of variables etc etc. These are runtime errors and you either have to write tests to catch them (hence visit very code block) or manually try and reach them. Some IDEs, like PHPStorm, can you get pretty far though. >Low barrier to entry gets you a lot of crummy projects As someone else mentioned in another comment, 1% of PHP projects succeeding is still a lot more than 20% of Haskell projects. >PHP is a lot easier to manage and maintain in production Except for when you need to scale. Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory for a PHP site to really run performant, adding quite an overhead to any production setup you'll get into.
  - combatentropy 10y ago
    Look, if you want to use something other than PHP, don't let me get in your way. However, if PHP is one thing, it is fast and always has been. > Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory We don't use any of that. We don't even use database connection pooling. Every request has to reopen the database. Every request has to reopen an LDAP connection to Active Directory for authentication. We are still on PHP 5.3 and we aren't using an opcache. We are using the memory-hungrier mod_php instead PHP-FPM, and we are using the slower, memory-hungrier Apache prefork instead of its newer event MPM. We are also running PostgreSQL on the same server. And yet PHP is connecting to the database over the slower network instead of UNIX domain sockets. Every request takes just a split second. The server's processor is running at 1-2%, with about half a gigabyte of RAM in use, a lot of which is probably the database. All those inefficient design decisions are artifacts of history that I hope eventually to revise out --- except for connection pooling, which I've read has its own problems. On my personal website I've been able to choose the newer and better things, but none of them were really more work to set up: Apache event MPM, Unix domain-socket connections, PHP-FPM, and PHP's OPcache.
chj 10y ago
Refactoring without a proper tool is like shooting at your own feet.
- Tehnix 10y ago
  Indeed, which is why it's nice to have a compiler catching things that you would have to write tests to catch in PHP.
  - chj 10y ago
    PHPStorm, highly recommended.
int_19h 10y ago
More importantly, said virtues don't have anything to do with PHP as a language, and everything with request handling in the server and the framework. Yes, in case of PHP, the latter is basically built-in, but you can (and we do) have equivalent functionality with all other languages out there. So if these are virtues, they also apply to Python, Ruby etc. And then - again - why PHP?

by Tehnix 10y ago

bkanber 10y ago

> Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run once. I mean, you're not reinitializing it, and it's not exactly slow. And when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere. > where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours I'm not really sure what you mean by that. Write a method, write tests for that method. Just because PHP has weird type coercion issues doesn't mean you can't be diligent about the types that you use. And of course tools like PhpStorm understand docblocks, annotations and PHP types and classes and basically does the same thing that a compiler does, it'll show you big honking type errors if you ask it to, it'll even stop you from committing broken code if you use that option. > Sure, a lot of people have done a lot of quite cool projects in PHP, but I would much more benefit that to the lower barrier to entry I don't know about that. Low barrier to entry gets you a lot of crummy projects. In my experience PHP is a lot easier to manage and maintain in production, and that's a huge advantage to companies and products with small teams.

Tehnix 10y ago
>when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere It's just as easy to scale with other languages, you would keep the data that needs to be persisted in a DB. The benefit comes from things that does not need to be persisted, like resource pooling, memoization, config loading etc. > > where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours >Write a method, write tests for that method Exactly, I need to write tests for things that are trivially verifiable by a compiler. And I'm not just talking about type coercion (which is a bad thing), but also missing function parameters, wrong parameters, missing initialization of variables etc etc. These are runtime errors and you either have to write tests to catch them (hence visit very code block) or manually try and reach them. Some IDEs, like PHPStorm, can you get pretty far though. >Low barrier to entry gets you a lot of crummy projects As someone else mentioned in another comment, 1% of PHP projects succeeding is still a lot more than 20% of Haskell projects. >PHP is a lot easier to manage and maintain in production Except for when you need to scale. Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory for a PHP site to really run performant, adding quite an overhead to any production setup you'll get into.
- combatentropy 10y ago
  Look, if you want to use something other than PHP, don't let me get in your way. However, if PHP is one thing, it is fast and always has been. > Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory We don't use any of that. We don't even use database connection pooling. Every request has to reopen the database. Every request has to reopen an LDAP connection to Active Directory for authentication. We are still on PHP 5.3 and we aren't using an opcache. We are using the memory-hungrier mod_php instead PHP-FPM, and we are using the slower, memory-hungrier Apache prefork instead of its newer event MPM. We are also running PostgreSQL on the same server. And yet PHP is connecting to the database over the slower network instead of UNIX domain sockets. Every request takes just a split second. The server's processor is running at 1-2%, with about half a gigabyte of RAM in use, a lot of which is probably the database. All those inefficient design decisions are artifacts of history that I hope eventually to revise out --- except for connection pooling, which I've read has its own problems. On my personal website I've been able to choose the newer and better things, but none of them were really more work to set up: Apache event MPM, Unix domain-socket connections, PHP-FPM, and PHP's OPcache.

chj 10y ago

Refactoring without a proper tool is like shooting at your own feet.

Tehnix 10y ago
Indeed, which is why it's nice to have a compiler catching things that you would have to write tests to catch in PHP.
- chj 10y ago
  PHPStorm, highly recommended.

int_19h 10y ago

More importantly, said virtues don't have anything to do with PHP as a language, and everything with request handling in the server and the framework. Yes, in case of PHP, the latter is basically built-in, but you can (and we do) have equivalent functionality with all other languages out there. So if these are virtues, they also apply to Python, Ruby etc. And then - again - why PHP?