3 ms·

It's easy to write code until you run into situations where you need more than a web framework. Got to run a job at midnight to pull in a daily dataset? You're

It's easy to write code until you run into situations where you need more than a web framework. Got to run a job at midnight to pull in a daily dataset? You're probably gonna be heading for the python book, or the ruby book, etc, to actually get the work done. Even in big companies that "use" php, I'd be willing to wager a significant portion of their actual runtime is written in C and the like as extensions, because PHP the language is so slow. This isn't even getting into problems with the runtime itself. PHP's treatment of every new request by giving it a brand new instance to run in slows things down considerably, because it has to do so much startup work -- creating database connections, etc -- before it can get going. Personally, PHP's ugliness is a death from a thousand papercuts sort of situation. Yes, no one feature is a killer, but all the little quirks add up to a language that is less useful and productive after a while.

wvenable 12y ago
> Got to run a job at midnight to pull in a daily dataset? You're probably gonna be heading for the python book, or the ruby book, etc, to actually get the work done. Nope. PHP has no problem with running jobs. Mixing code-bases for this kind of thing would be a bad idea. > because PHP the language is so slow. That is definitely true but you're still waiting more on IO than the language itself. So really, most people aren't use C extensions. > PHP's treatment of every new request by giving it a brand new instance to run in slows things down considerably, because it has to do so much startup work -- creating database connections, etc -- before it can get going. Database connections are pooled, of course. Byte code is cached. In my case, PHP doesn't even touch the disk when it loads -- all the compiled byte code is in RAM. Instances of PHP are pooled with Apache children as well. And, of course, you can run PHP just like you run Ruby and Python without about the same amount of configuration of the web server. > Personally, PHP's ugliness is a death from a thousand papercuts sort of situation. Most of PHP's ugliness is legacy stuff (badly named functions, etc) that are pretty much old news and hardly restricting.

wvenable 12y ago

> Got to run a job at midnight to pull in a daily dataset? You're probably gonna be heading for the python book, or the ruby book, etc, to actually get the work done. Nope. PHP has no problem with running jobs. Mixing code-bases for this kind of thing would be a bad idea. > because PHP the language is so slow. That is definitely true but you're still waiting more on IO than the language itself. So really, most people aren't use C extensions. > PHP's treatment of every new request by giving it a brand new instance to run in slows things down considerably, because it has to do so much startup work -- creating database connections, etc -- before it can get going. Database connections are pooled, of course. Byte code is cached. In my case, PHP doesn't even touch the disk when it loads -- all the compiled byte code is in RAM. Instances of PHP are pooled with Apache children as well. And, of course, you can run PHP just like you run Ruby and Python without about the same amount of configuration of the web server. > Personally, PHP's ugliness is a death from a thousand papercuts sort of situation. Most of PHP's ugliness is legacy stuff (badly named functions, etc) that are pretty much old news and hardly restricting.