6 ms·

Let me make sure I understand... Is this meant to be run on a web hosting service that supports PHP in the 'traditional' way or do you need permission to run t

Let me make sure I understand... Is this meant to be run on a web hosting service that supports PHP in the 'traditional' way or do you need permission to run this as a daemon? If it's the former, I can definitely see its benefits, but if it's the latter I can only imagine the target audience being people who refuse to program in anything but PHP and people who are by some bizarre policy required to use PHP but are allowed to run their own HTTP server.

vog 14y ago
I fully agree that for a new project, you shouldn't use PHP for any other reason than the ubiquitous hosting. However, for existing projects and/or existing teams there might be another reason to stick with PHP: As a common denominator across all team members.
- Edootjuh 14y ago
  I hadn't thought of that. You also made me realize that existing modules written in PHP can be reused this way.
- jtreminio 14y ago
  Or because I really enjoy using it, I'm comfortable in it, and my products work? Blanket statements like yours reek of elitism and have no real value behind them, other than "this language sucks you should use this one".
  - ralfn 14y ago
    Not all quality aspects of language design are subjective. Even its authors fully emphasize that this is not how they would intenionally design a language, but PHP just kind of grew from a template system and very practical requirements. There are many reasons to pick/use PHP, indispite its (lack of proper) language design. Easy to find extremly cheap programmers. Easy and cheap to host. Good and fast c based libraries. But in no reality is its language design considered competitive by any one except by uneducated hobbyists.
    - jtreminio 14y ago
      Define competitive? I didn't realize all languages were in a competition to be... what? The best? I write in PHP not because it is my hobby, but because I know it very well and it makes me a lot of money. The companies I work for use PHP because they can find many talented developers. Using a proper framework, being very strict about unit testing, and following other best practices makes our codebase a joy to work with. I'm sorry if you feel this isn't possible with PHP, but my point of elitism still stands. Who cares if PHP isn't "competitive", whatever that means? It works, we can create applications that are used by thousands of people a day to do important things (online education in my case), and most of all it brings in money.
      - neilk 14y ago
        You're right, that with proper vigilance, PHP is a very productive tool. No one is criticizing you for correctly perceiving the business value there. I used PHP professionally for almost four years, at places like Flickr and Wikipedia. It definitely packs a lot of power - it's fast at what it does, has every library you probably want built in already or available with a little config. And, out of the box, it matches the request-response loop in web programming much more simply than most languages do. Unfortunately, even with these good qualities, PHP just has a lot of misdesign in it. It's not elitism to point this out. Just look carefully at your own practices and you'll see that a lot of what you do is defending yourself against bad practices that PHP is subtly (or unsubtly) trying to impose on you. It's telling that PHP is a template language, but in order to achieve useful results, you really have to use another template language on top of it, like Smarty or Symfony or whatever the cool thing is these days. And even so, to this day, Rasmus thinks that such frameworks are misguided, and that real programmers should just use the built-in templating of PHP (i.e. embedding blocks of code in HTML) and nothing else. How anyone can work for over 15 years on the web and still think this is beyond me. For most of its existence PHP's only guiding principle was expediency and one-off hacks. That's how you get a 'feature' where you can inject evil values into the script just by parsing CGI arguments. Or, the ability to just ignore errors by prepending an at sign. This is almost NEVER a good idea, and introducing a feature like that means that in any large project you never can be sure what's really going on, without actually looking for all instances of this all the time. And what kind of language makes a keyword like 'array()'? PHP is a supposedly dynamic language, but it almost goes out of its way to make manipulating complex data structures difficult. Compare to Perl and Python, which make deep data structures easy and also easy to transform and manipulate. Instead PHP has insecure, hacky misfeatures like variable variable names. This is something that beginner programmers often want, until they learn about actual data structures. I have a feeling you may not be all that familiar with other languages, or for that matter, PHP. There are experts who choose PHP, but they acknowledge these difficulties.
  - ma2rten 14y ago
    As someone who worked for a major European social network written in PHP, I can say with full confidence that PHP's syntax and it's standard libraries are objectively worse than those of other languages (as in inconsistent and less productive). That being said there definitively good frameworks out there for PHP and having good libraries is much more important than the syntax of the language, so becoming familiar enough with another language until you are as productive as with PHP might not be worth the effort for you.
    - nolok 14y ago
      "As someone who made his own opinion on the subject, I can objectively say that my opinion is the right one" Seriously ... It doesn't matter which language is "objectively better as a programming language", just use whatever you enjoy the most. If it's PHP, then have fun coding in it rather that use something else because some people on the internet think you should. There are tons of very successful project in PHP, including giant ones, because at some point you stop circlejerking and start coding. Just make sure you know what else exists out there and try other things here and there to discover new languages and other ways to do things, but that's a general programming rule, not something limited to php.
      - billpatrianakos 14y ago
        Amen to that. The minute someone utters PHP someone else inevitably goes out of their way to let you know it sucks even if it's not at all relevant to anything you're talking about like in this case. Guess what? Every language, framework, technique, theory, etc. sucks because someone else thinks theirs is better. "Oh youre a JavaScript person? Eww, action script is better, yours sucks. Like C++? Gross! ISO C is far superior! Using Rails? Well I feel sorry for you because Sinatra is faster and less bloated". Point is, no matter what your platform, stack, or combination of technology choices are someone will inevitably rant about how it sucks then get a blog post about it on the front page of HN. Seriously, enough with the crusades and religious fervor over your development choices. Let's compare apples to apples and be constructive in our criticisms. Instead of looking at nodephp and balking because it's in PHP how about criticizing it based on its merits. What are the goals? Does it achieve those goals? Are there similar projects that do it better? What are the use cases for this? This thread started that way and is now devolving into another religious dispute. Comparing it to nodejs is fair if you take into account that it's best used by those with hosting restrictions or people who are just partial to PHP and those who want to use it with large existing projects. It's not fair to throw out general "PHP sucks" arguments. That's not relevant. Sucky or not, does this software work and is it useful? Yeah.
  - lobo_tuerto 14y ago
    This is not a blank statement: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de... Previous discussion: http://news.ycombinator.com/item?id=3820431 http://news.ycombinator.com/item?id=3820431
    - notJim 14y ago
      S/he's not denying that PHP is a crappy language. He's saying that he's comfortable building successful in PHP. You're saying “Don't use PHP, it sucks.” He's saying, “I don't care, it lets me turn code into money and that's all I want.”
- notJim 14y ago
  > I fully agree that for a new project, you shouldn't use PHP for any other reason than the ubiquitous hosting. Here's another scenario where I could imagine using PHP. Suppose I'm starting a company, and I'm starting it solo. I've been using PHP successfully for many years, and I know it and the environment (Apache, etc.) really well. I know what libraries are good, what libraries are not good, I have a framework that I like, and that I know how to set up to my liking. By the way, I'm really excited about this company. Now, PHP is pretty awful as a programming language. I really don't like it. But the reality is, I am going be dramatically more efficient with it. If I were to use Rails, it would take me at the very least a week or two to really be able to use it without checking documentation constantly, and it would probably take me months to be at a proficiency where I was totally comfortable with it, and the environment it lives in, and figured out which libraries to use with it and so on. During those months, when I should be focussing on building my business, talking to customers, getting feedback, learning more about marketing, I am instead dealing with the friction of learning a new programming environment. If I had stuck with PHP, all I have to do is sit at a terminal and let the code flow out of my fingertips. All of my actual thinking could go into the important stuff. I don't deny that PHP is pretty terrible as a programing language. I do however deny that there are no reasons to use it for a new project.
FuzzyDunlop 14y ago
I'm interested as to how you'd run it as a server without PHP 5.4. Looking at the code, it's written to be compatible with PHP >= 5.3.2, and the composer.json doesn't specify 5.4 as the minimum version. It also wraps Silex and includes Guzzle (some sort of API consuming thing). Trying to gain credibility from using Node's name seems a little disingenuous given that it's microframework with an event loop of some sort plugged in, and an analogous 'hello world'.
- encoderer 14y ago
  I think you're hung-up on the integrated webserver that ships with PHP 5.4. All a "server" is, is a daemon that listens on a port. That's what it does. And it uses LibEvent thus the "node" comparisons. Though I agree with whomever said that it would be better to compare this to Tornado.
  - FuzzyDunlop 14y ago
    I noticed it only uses libevent if the PECL dependency is satisfied. I'm not aware if this is now packaged by default, but I don't have it installed. I can imagine any event-based library will now warrant a comparison to Node. However, I've not seen things like EventMachine calling itself Node.Ruby, or Tornado calling itself Node.Python. Or NginX calling itself Node.Server. That's my bugbear. It feels like linkbait. Re: the server stuff. I was poorly trying to make the point you made further up, about PHP not being well suited to long running processes or being daemonised. I may well be wrong, but each request will get its own event loop, no?
kamaal 14y ago
>>I can only imagine the target audience being people who refuse to program in anything but PHP Such people exist in every language community. You name the famous language and there you will fine people wanting to do everything in that language. This is nothing to specific to php. There are various reasons for that, Once a person learns a language it becomes an investment- In time and other things and, as time grows out a person begins to think in that language, its paradigms, its idiomatic way of working. He may learn more than one language. But he will bear allegiance to one specific language.
- adeelk 14y ago
  I don’t think that was intended to be an attack on PHP.
encoderer 14y ago
Let me preface this with a full disclosure: I've also waded into the depths of many of the PHP APIs that the OP has used to produce this project. I've created a general-purpose PHP daemon library (http://shaneharter.github.com/PHP-Daemon/ http://shaneharter.github.com/PHP-Daemon/). There is no question that the PHP implementation of these APIs (think: Socket, SystemV, POSIX, etc) is very underwhelming compared to something you'd get in Python, Java, or nearly any language. And it's partly because of that that I felt it would be irresponsible for me not to include a disclaimer at the top of my github readme: For many reasons PHP is not an optimal language choice for creating servers or daemons. I created this library so if you must use PHP for these things, you can do it with ease and produce great results. But if you have the choice, Java, Python, Ruby, etc, are all better suited for this. So that being said: With a general-purpose daemon library, there's a 3rd use-case to what you described: People who need to create daemons/servers/etc that use a large existing codebase: maybe it needs to share the 80 models that run your primary website. Maybe you've written a large domain-specific library. That sort of thing. While it's a little more difficult for me to apply those reasons to a Tornado port, I'd like to hear from the developers first before I dismissed their work.
- hinathan 14y ago
  This was exactly the situation for us at PBworks when I wrote my version of OP's system — huge existing business logic and object model in php but with new requirements and performance demands. Move the business logic into a stateful backend REST daemon instead of the frontend web servers, without throwing away all of the existing codebase. In one move you get the ability to load balance more naturally and persist data in-thread instead of e.g. huge memcache traffic for each user request.
  - ma2rten 14y ago
    The idea is pretty cool actually, but I am wondering: Is the advantage is really that huge over just running a normal PHP stack on the backend server in combination with local memcache?
    - 14y ago

vog 14y ago

I fully agree that for a new project, you shouldn't use PHP for any other reason than the ubiquitous hosting. However, for existing projects and/or existing teams there might be another reason to stick with PHP: As a common denominator across all team members.

Edootjuh 14y ago
I hadn't thought of that. You also made me realize that existing modules written in PHP can be reused this way.
jtreminio 14y ago
Or because I really enjoy using it, I'm comfortable in it, and my products work? Blanket statements like yours reek of elitism and have no real value behind them, other than "this language sucks you should use this one".
- ralfn 14y ago
  Not all quality aspects of language design are subjective. Even its authors fully emphasize that this is not how they would intenionally design a language, but PHP just kind of grew from a template system and very practical requirements. There are many reasons to pick/use PHP, indispite its (lack of proper) language design. Easy to find extremly cheap programmers. Easy and cheap to host. Good and fast c based libraries. But in no reality is its language design considered competitive by any one except by uneducated hobbyists.
  - jtreminio 14y ago
    Define competitive? I didn't realize all languages were in a competition to be... what? The best? I write in PHP not because it is my hobby, but because I know it very well and it makes me a lot of money. The companies I work for use PHP because they can find many talented developers. Using a proper framework, being very strict about unit testing, and following other best practices makes our codebase a joy to work with. I'm sorry if you feel this isn't possible with PHP, but my point of elitism still stands. Who cares if PHP isn't "competitive", whatever that means? It works, we can create applications that are used by thousands of people a day to do important things (online education in my case), and most of all it brings in money.
    - neilk 14y ago
      You're right, that with proper vigilance, PHP is a very productive tool. No one is criticizing you for correctly perceiving the business value there. I used PHP professionally for almost four years, at places like Flickr and Wikipedia. It definitely packs a lot of power - it's fast at what it does, has every library you probably want built in already or available with a little config. And, out of the box, it matches the request-response loop in web programming much more simply than most languages do. Unfortunately, even with these good qualities, PHP just has a lot of misdesign in it. It's not elitism to point this out. Just look carefully at your own practices and you'll see that a lot of what you do is defending yourself against bad practices that PHP is subtly (or unsubtly) trying to impose on you. It's telling that PHP is a template language, but in order to achieve useful results, you really have to use another template language on top of it, like Smarty or Symfony or whatever the cool thing is these days. And even so, to this day, Rasmus thinks that such frameworks are misguided, and that real programmers should just use the built-in templating of PHP (i.e. embedding blocks of code in HTML) and nothing else. How anyone can work for over 15 years on the web and still think this is beyond me. For most of its existence PHP's only guiding principle was expediency and one-off hacks. That's how you get a 'feature' where you can inject evil values into the script just by parsing CGI arguments. Or, the ability to just ignore errors by prepending an at sign. This is almost NEVER a good idea, and introducing a feature like that means that in any large project you never can be sure what's really going on, without actually looking for all instances of this all the time. And what kind of language makes a keyword like 'array()'? PHP is a supposedly dynamic language, but it almost goes out of its way to make manipulating complex data structures difficult. Compare to Perl and Python, which make deep data structures easy and also easy to transform and manipulate. Instead PHP has insecure, hacky misfeatures like variable variable names. This is something that beginner programmers often want, until they learn about actual data structures. I have a feeling you may not be all that familiar with other languages, or for that matter, PHP. There are experts who choose PHP, but they acknowledge these difficulties.
- ma2rten 14y ago
  As someone who worked for a major European social network written in PHP, I can say with full confidence that PHP's syntax and it's standard libraries are objectively worse than those of other languages (as in inconsistent and less productive). That being said there definitively good frameworks out there for PHP and having good libraries is much more important than the syntax of the language, so becoming familiar enough with another language until you are as productive as with PHP might not be worth the effort for you.
  - nolok 14y ago
    "As someone who made his own opinion on the subject, I can objectively say that my opinion is the right one" Seriously ... It doesn't matter which language is "objectively better as a programming language", just use whatever you enjoy the most. If it's PHP, then have fun coding in it rather that use something else because some people on the internet think you should. There are tons of very successful project in PHP, including giant ones, because at some point you stop circlejerking and start coding. Just make sure you know what else exists out there and try other things here and there to discover new languages and other ways to do things, but that's a general programming rule, not something limited to php.
    - billpatrianakos 14y ago
      Amen to that. The minute someone utters PHP someone else inevitably goes out of their way to let you know it sucks even if it's not at all relevant to anything you're talking about like in this case. Guess what? Every language, framework, technique, theory, etc. sucks because someone else thinks theirs is better. "Oh youre a JavaScript person? Eww, action script is better, yours sucks. Like C++? Gross! ISO C is far superior! Using Rails? Well I feel sorry for you because Sinatra is faster and less bloated". Point is, no matter what your platform, stack, or combination of technology choices are someone will inevitably rant about how it sucks then get a blog post about it on the front page of HN. Seriously, enough with the crusades and religious fervor over your development choices. Let's compare apples to apples and be constructive in our criticisms. Instead of looking at nodephp and balking because it's in PHP how about criticizing it based on its merits. What are the goals? Does it achieve those goals? Are there similar projects that do it better? What are the use cases for this? This thread started that way and is now devolving into another religious dispute. Comparing it to nodejs is fair if you take into account that it's best used by those with hosting restrictions or people who are just partial to PHP and those who want to use it with large existing projects. It's not fair to throw out general "PHP sucks" arguments. That's not relevant. Sucky or not, does this software work and is it useful? Yeah.
- lobo_tuerto 14y ago
  This is not a blank statement: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de... Previous discussion: http://news.ycombinator.com/item?id=3820431 http://news.ycombinator.com/item?id=3820431
  - notJim 14y ago
    S/he's not denying that PHP is a crappy language. He's saying that he's comfortable building successful in PHP. You're saying “Don't use PHP, it sucks.” He's saying, “I don't care, it lets me turn code into money and that's all I want.”
notJim 14y ago
> I fully agree that for a new project, you shouldn't use PHP for any other reason than the ubiquitous hosting. Here's another scenario where I could imagine using PHP. Suppose I'm starting a company, and I'm starting it solo. I've been using PHP successfully for many years, and I know it and the environment (Apache, etc.) really well. I know what libraries are good, what libraries are not good, I have a framework that I like, and that I know how to set up to my liking. By the way, I'm really excited about this company. Now, PHP is pretty awful as a programming language. I really don't like it. But the reality is, I am going be dramatically more efficient with it. If I were to use Rails, it would take me at the very least a week or two to really be able to use it without checking documentation constantly, and it would probably take me months to be at a proficiency where I was totally comfortable with it, and the environment it lives in, and figured out which libraries to use with it and so on. During those months, when I should be focussing on building my business, talking to customers, getting feedback, learning more about marketing, I am instead dealing with the friction of learning a new programming environment. If I had stuck with PHP, all I have to do is sit at a terminal and let the code flow out of my fingertips. All of my actual thinking could go into the important stuff. I don't deny that PHP is pretty terrible as a programing language. I do however deny that there are no reasons to use it for a new project.

FuzzyDunlop 14y ago

I'm interested as to how you'd run it as a server without PHP 5.4. Looking at the code, it's written to be compatible with PHP >= 5.3.2, and the composer.json doesn't specify 5.4 as the minimum version. It also wraps Silex and includes Guzzle (some sort of API consuming thing). Trying to gain credibility from using Node's name seems a little disingenuous given that it's microframework with an event loop of some sort plugged in, and an analogous 'hello world'.

encoderer 14y ago
I think you're hung-up on the integrated webserver that ships with PHP 5.4. All a "server" is, is a daemon that listens on a port. That's what it does. And it uses LibEvent thus the "node" comparisons. Though I agree with whomever said that it would be better to compare this to Tornado.
- FuzzyDunlop 14y ago
  I noticed it only uses libevent if the PECL dependency is satisfied. I'm not aware if this is now packaged by default, but I don't have it installed. I can imagine any event-based library will now warrant a comparison to Node. However, I've not seen things like EventMachine calling itself Node.Ruby, or Tornado calling itself Node.Python. Or NginX calling itself Node.Server. That's my bugbear. It feels like linkbait. Re: the server stuff. I was poorly trying to make the point you made further up, about PHP not being well suited to long running processes or being daemonised. I may well be wrong, but each request will get its own event loop, no?

kamaal 14y ago

>>I can only imagine the target audience being people who refuse to program in anything but PHP Such people exist in every language community. You name the famous language and there you will fine people wanting to do everything in that language. This is nothing to specific to php. There are various reasons for that, Once a person learns a language it becomes an investment- In time and other things and, as time grows out a person begins to think in that language, its paradigms, its idiomatic way of working. He may learn more than one language. But he will bear allegiance to one specific language.

adeelk 14y ago
I don’t think that was intended to be an attack on PHP.

encoderer 14y ago

Let me preface this with a full disclosure: I've also waded into the depths of many of the PHP APIs that the OP has used to produce this project. I've created a general-purpose PHP daemon library (http://shaneharter.github.com/PHP-Daemon/ http://shaneharter.github.com/PHP-Daemon/). There is no question that the PHP implementation of these APIs (think: Socket, SystemV, POSIX, etc) is very underwhelming compared to something you'd get in Python, Java, or nearly any language. And it's partly because of that that I felt it would be irresponsible for me not to include a disclaimer at the top of my github readme: For many reasons PHP is not an optimal language choice for creating servers or daemons. I created this library so if you must use PHP for these things, you can do it with ease and produce great results. But if you have the choice, Java, Python, Ruby, etc, are all better suited for this. So that being said: With a general-purpose daemon library, there's a 3rd use-case to what you described: People who need to create daemons/servers/etc that use a large existing codebase: maybe it needs to share the 80 models that run your primary website. Maybe you've written a large domain-specific library. That sort of thing. While it's a little more difficult for me to apply those reasons to a Tornado port, I'd like to hear from the developers first before I dismissed their work.

hinathan 14y ago
This was exactly the situation for us at PBworks when I wrote my version of OP's system — huge existing business logic and object model in php but with new requirements and performance demands. Move the business logic into a stateful backend REST daemon instead of the frontend web servers, without throwing away all of the existing codebase. In one move you get the ability to load balance more naturally and persist data in-thread instead of e.g. huge memcache traffic for each user request.
- ma2rten 14y ago
  The idea is pretty cool actually, but I am wondering: Is the advantage is really that huge over just running a normal PHP stack on the backend server in combination with local memcache?
  - 14y ago