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.
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/).
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.
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.
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?
It is if you need to consider so many objects during a request that the memcached request and deserialization becomes too much time per API operation (requests like visible object ids in an unbounded folder with acls/permissions applied per item)
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.
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.
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.
A thoughtful critique of PHP. Good. Here's the thing, for those of us who use PHP on a daily basis, we are all well aware of all of this.
I have almost 100K lines of PHP code and only one of them spits out HTML. That would be the line that fetches the initial HTML template which is static and spits it out. After that, everything is XHR and web sockets. The DOM is manipulated directly by client-side JavaScript.
Why use PHP? Libraries to use any database I can imagine. Existing libraries for any API I can imagine. Language maturity. Familiarity and similarity to C.
I know the mines and I stay away. On top of that, those maintaining the language are aware of them too and they are slowly deprecating them.
> PHP is a supposedly dynamic language, but it almost goes out of its way to make manipulating complex data structures difficult.
Why would you use complex data structures in PHP? If you did, why try to manipulate them?
PHP is a language that is made for the web. On the web, anything that is computation heavy, like data manipulation, should be done on the client's side. Not that JavaScript is much better at data structures and manipulation, but at least it probably has a monster of a CPU and a boatload of RAM to smooth things over.
Even more relevant for professional use is platform ubiquity. PHP is simply more widespread. That has real value! If you encounter a problem, someone else ran into it as well. If it's a legitimate error in PHP, it'll get fixed and will get attention. On other platforms? Yours may be the sole voice on the issue. Nobody will listen. Been there, done that. No thanks.
"PHP is simply more widespread. That has real value!"
"If you encounter a problem, someone else ran into it as well."
So you imply you can't be the first anymore to run into a new problem with PHP?
"If it's a legitimate error in PHP, it'll get fixed and will get attention."
If you find a legitimate error in the implementation of _any_ language it'll get fixed and will get attention. Unless it's abandoned, or no longer mantained.
"On other platforms? Yours may be the sole voice on the issue. Nobody will listen."
I did not claim one cannot run succesfull projects in PHP. I stated the exact opposite. And im doing that again now, in the hope your reading is just suddenly improved.
PHP has a legacy. It started off as a template language, and slowly got more and more control structures. So, its an accidental programming language.
Language are not competitive, but language design features sure are. Nobody with the actual skillset to design and implement a programming language would consider, for example, merging vectors and dictionaries into some kind of mutated frankenarray.
This does not make the language unusable. And language design features are not the most crucial arguments to pick one language over the other in the short term. But they are, for a community and industry in the long term.
To my surprise, i read in this thread that PHP now finally has a cyclic garbage collector. That's a good example of a competitive language design feature, which utility is not in any way subjective. A large range of algorithms and design patterns couldn't be implemented efficiently or effectively without this particular feature.
And its too easy to cry "elitism" every time somebody points this out.
>>Nobody with the actual skillset to design and implement a programming language would consider, for example, merging vectors and dictionaries into some kind of mutated frankenarray.
>Actually, JavaScript and Lua have merged vectors and Dictionaries.
I'm not sure about Lua, but in the case of Javascript, it's not entirely true. Arrays are objects, yes, but objects are not arrays.
So, unless you are extending the build-in array type, objects do not behave as arrays. They are not recognized as arrays, and more importantly, no modern javascript engine actually implements arrays as hashes.
For example {}.length has no value. It does not have a length of zero, it does not have a length at all. Visa versa, when looking at an object-map as a 'map', you'll get the array entries, as well as the length property, and the push and pop methods.
It's orthogonal. Imagine a javascript engine having no special implementation for an Array. We could implement it on top of the object-map. So, an array does not behave as a map, its implemented in a map. There's a clear distinction.
But the parallels with PHP are interesting. Both languages were not designed with the intent of large applications, but with the intent of adding a small piece of isolated logic to what is mostly a template. Both languages have had a lot of flack for their early design choices as well. People are still upset how Javascript handles casting (which is similar to how PHP handles it), and they are still upset how Javascript handles scoping (which is again similar to how PHP handles it).
Where the languages start differing, is that Javascript is much more reflective, which allows one to fix many language flaws in library or framework code, to suit different use-cases like the development of large scale projects. (just consider the hundreds of class-based systems implemented in Javascript)
But even for Javascript, the same logic applies. Considering the role and purpose it has now, the language design would have been different, if it was not for backwards compatibility.
And there as well, people are trying to figure out ways to make it radically better. Dart comes to mind. Compiling other languages into javascript. (coffeescript, gwt, etc.)
And even arguments in favor of Node.js are all based on the assumption that we are stuck with Javascript in the browser.
And just as with PHP, the original authors themselves, make no secret that their language design wasn't optimized or optimal for how we are using it now.
Nobody with the actual skillset to design and implement a programming language would consider, for example, merging vectors and dictionaries into some kind of mutated frankenarray.
Actually, JavaScript and Lua have merged vectors and Dictionaries.
> Nobody with the actual skillset to design and implement a programming language would consider, for example, merging vectors and dictionaries into some kind of mutated frankenarray.
Whats the order of complexity of adding an element in the middle of "an array" in PHP?
So, it's bad, because it makes it very confusing, what the exact implementation is. If you can't tell how much slower your algorithm that calculates something from an 'frankenarray' gets, when the array gets bigger, you have a problem.
That's one problem. The other problem is with language itself. When we call something an array, which isn't actually an array (an array being a very specific implementation of a vector) people get confused.
Imagine how you would feel if PHP used the word 'variable' to mean function and the word 'function' to mean variable.
So, a hash and an array are not just semantically different (that they refer to a completely different ADT's), but they are also completely distinct implementations of those ADT's.
Now, this is not a problem, when you are using PHP as it was originally intended. To add a small bit of logic to a template that mostly uses fast, well written c functions in it's built-in library.
But people are abusing PHP to write large scale libraries and frameworks. Many riddled with security issues, and unpredictable performance bottlenecks, because the language wasn't designed to actually allow you to write well defined algorithms.
Now, we've seen workarounds for these problems. Facebook wrote a PHP to C compiler, and moved all crucial algorithms to C. You can use unit-testing to supplement the lack of any usable type information, and to combat the automatic casting that PHP does (which creates all kinds of bugs in edge cases, that is hard to track or test against). You can use profiling to track performance issues, and fix code that interacts with frankenarrays, in a sort of trail-and-error kind of way.
People once wrote all their code in ASM. Discipline can make all the difference. But highly skilled disciplined, well educated professionals aren't the target audience of PHP.
All this required discipline can be justified on practical grounds. PHP programmers are generally paid the worst (or as an employer would call, are the cheapest). Hosting is cheap. And for many use-cases you can just drop in ready to go code (Wordpress, Drupal, Joombla, etc.) and just skin it.
So, i'm not saying picking PHP is a bad financial choice for a company. If you don't take on difficult projects, and don't intent to hire highly skilled coders, it can be cheap and productive.
> But people are abusing PHP to write large scale libraries and frameworks. Many riddled with security issues, and unpredictable performance bottlenecks, because the language wasn't designed to actually allow you to write well defined algorithms.
I mostly agree with your post but you've gone way over the top on this statement. PHP is pretty analogous to the majority of languages in terms of syntax, structure, and capability. Frameworks written in PHP are no more likely to have security issues or unpredictable performance bottlenecks than any other language. Certainly nothing prevents you from writing well defined algorithms.
PHP's "arrays" are both vectors and hash tables at the same time. I agree that there is no reason to combine those concepts (although I love ordered hash tables). But ultimately there isn't much harm in it; it's just an extreme example of typelessness.
>> But people are abusing PHP to write large scale libraries and frameworks. Many riddled with security issues, and unpredictable performance bottlenecks, because the language wasn't designed to actually allow you to write well defined algorithms.
>I mostly agree with your post but you've gone way over the top on this statement.
You are right, i went over board.
>Frameworks written in PHP are no more likely to have security issues or unpredictable performance bottlenecks than any other language
I suspect there is a measurable relationship between average quality of ecosystem and how easily or difficult a language is to use. But that would not be a fair argument: a language being easy should be a good thing.
>Certainly nothing prevents you from writing well defined algorithms.
Well, not being able to guess the order of complexity of many of the core operations on datastructures, does make it a lot harder. It's generally undefined, at least by the language spec. And when the internal implementations of core datastructures change between versions, you can't even reliably implement the typical collection of sorting algorithms.
The reasons this isn't a problem at the smale scale, is that the most common operations are actually all build-in with good defaults.
>But ultimately there isn't much harm in it; it's just an extreme example of typelessness.
PHP is not typeless, just messy with types. Depending on the type, you can use different syntactical operators and you are unable to implement those same contructs for other types. Also dependent on the type, is the difference between value- and object- semantics. However, this logic is not consist with the actual algorithmic complexity. Strings are copy-on-write, for example. So you are technically passing a reference (from a performance POV), but acting like it's not.
PHP is a dynamically typed language, with lots of run-time type errors, when things don't match. We even have all kinds of functions to determine types. It's definately not typeless.
> Strings are copy-on-write, for example. So you are technically passing a reference (from a performance POV), but acting like it's not.
That's just an optimization; it's not a very significant detail. All languages have these little details. Java, for example, caches and reuses Number instances if the value is below 127.
> PHP is a dynamically typed language
It's also weakly typed. You can, for the most part, assume that the type isn't very important. If you've got the value 12, it doesn't matter much if it's stored as an int, float, or string. But obviously if you attempt to do an operation not supported by the value then you'll get an error. There's nothing surprising about that.
PHP arrays just take the idea of an index and allow it to be both strings or integers. In both cases, you're providing a value for the key and getting out another value. It's pretty easy to explain. The issue, I'd say, is that programmers rarely ever index by both integers and strings in the same structure. There are also performance differences but hash tables are so fast that you need to be doing something unusual for it to matter.
It's interesting that I asked a simple technical question, and rather than just answering it, you threw in a slew of insults and opinions about PHP and PHP programmers. Why do you have such strong feelings about PHP and PHP programmers so much? How long did you actually use PHP, and which companies did you work for that used it?
It's not your assertion that PHP is a crappy language that I disagree with. I fully agree there. Where I disagree with you is in your assessment that a) there aren't many skilled programmers who use PHP, and c) language features of PHP make it very difficult or impossible to write well-designed software.
As to your assertion that PHP is only good for simple projects employing low-skilled developers, tell that to the various PHP startups paying top dollar for skilled PHP developers.
PHP arrays are actually ordered hash tables. This information is readily available. If you really need a real array, there is SplArray.
> Now, we've seen workarounds for these problems. Facebook wrote a PHP to C compiler, and moved all crucial algorithms to C.
At the scale of Facebook, nobody uses scripting languages, so I doubt this is purely because of PHP. This would be like me telling you to not to use RoR because Twitter switched to Scala (people said this, but those people are stupid and I'm not among them.) Twitter and Facebook have problems you and I are unlikely to have.
> You can use unit-testing to supplement the lack of any usable type information, and to combat the automatic casting that PHP does (which creates all kinds of bugs in edge cases, that is hard to track or test against). You can use profiling to track performance issues, and fix code that interacts with frankenarrays, in a sort of trail-and-error kind of way.
PHP's type system is crazy, that is absolutely true. But it's not as hard to work around or as frequently a problem as you're suggesting, at least in my experience. JavaScript is another language that has a crazy-ish type system, but it doesn't get the hate that PHP does.
I have never had a case where PHP's arrays caused performance problems, but that's probably because I've also never written an application that didn't interact with some kind of back-end store like a database that was inevitable slower. I've done a fair amount of work to make apps faster, and the big wins were always in fixing bad data access or caching patterns and algorithms. I imagine that there would be a point when I need to worry about not using PHP arrays, but I guess I haven't hit it. And again, if/when I do, there's always SplArray.
> But people are abusing PHP to write large scale libraries and frameworks. Many riddled with security issues, and unpredictable performance bottlenecks, because the language wasn't designed to actually allow you to write well defined algorithms.
There are some really shitty PHP projects. I suspect a big part of that is that they took off before there was the widespread knowledge of best-practices we have now. (I'm assuming you're thinking of wordpress, drupal and joomla.) I've worked with Wordpress a bit, unfortunately, and the main reason it's so damned slow is because the queries are badly written, and the data access and caching patterns are awful. PHP's arrays never crossed my mind as a bottleneck, because they don't even show up in my profiling tools.
For what it's worth, I used to see a lot of people's code because the company I worked for required code samples when we were interviewing people. I saw a lot of really shitty RoR code, and I do not blame that on the language or the framework.
>It's interesting that I asked a simple technical question, and rather than just answering it,
Your question was:
Why is this bad? (referring to frankenarrays of PHP)
The summary of my answer was:
1. you can't easily tell the algorithmic complexity of most algorithms in PHP involving these "arrays"
2. naming something an array, that doesn't have the associated algorithmic complexity of an array, is misleading and hurts education, research and knowledge sharing.
I explained both these answers, with two examples:
1. Whats the order of complexity of adding an element in the middle of "an array" in PHP? (i'll answer: its undefined)
2. What would you think if PHP named a function a a variable, and a variable a function?
So, I did in detail answer you question.
> you threw in a slew of insults and opinions about PHP and PHP programmers.
It wasn't meant to be insulting. And the majority of my reply was a direct answer to your question. I think it was just a bit too broadly stated, for you to see the forest through the trees of my answer. And then i went off topic for your particular reply.
>Where I disagree with you is in your assessment that a) there aren't many skilled programmers who use PHP, and c) language features of PHP make it very difficult or impossible to write well-designed software.
a) didn't make that assement
b) ??
c) difficult, yes
>As to your assertion that PHP is only good for simple projects employing low-skilled developers, tell that to the various PHP startups paying top dollar for skilled PHP developers.
No, my assertion was that PHP is only a good economic choice, when you choose to hire low-skilled, cheap employees. That's its niche.
>Twitter and Facebook have problems you and I are unlikely to have.
Agree. But that does not make what Facebook did with PHP, anything less than working around the issues caused by the initial commitment to PHP.
>JavaScript is another language that has a crazy-ish type system, but it doesn't get the hate that PHP does.
But it did. Even now, claiming that Javascript's language design isn't optimal isn't somethign people will argue against. Say the same thing about PHP, and you get threads like these...
>I have never had a case where PHP's arrays caused performance problems, but that's probably because I've also never written an application that didn't interact with some kind of back-end store like a database that was inevitable slower.
Now, the type of problems I'm pointing at, are the ones that read their head when the datasize gets larger. For example, an algorithm interacting with an array in PHP. Every loop it inserts or removes an element. Now depending on where that data can be found in the array, and if it's key is a number or a string, if these number-keys are close together in range or not, the algorithmic complexity is anything from O(n) to (2^n).
In other words, the normal fauna of sorting algorithms are very hard, if not impossible to correctly implement in PHP.
This is not very relevant, if you just need a good sorting function for your array, since that is build-in. This is not relevant if you datasizes are always small.
So, this is not relevant in the small-scale world. But if there is a chance that will need to be implementing a complicated algorithm in PHP, that perhaps needs to interact with large datastructures, than PHP is a dangerous choice.
Beyond the limited scope of a database powered template with a bit of logic, it is simply not suited. It is not designed well enough to be 'general purpose' programming language, and its civic duty of all to warn those who think it is. (like the authors of this Node.php project)
While this is merely anecdotal, I feel compelled to note that I'm a PHP programmer -- as well as a Python and a Ruby programmer (in the sense of "somebody has paid me going market rates for working in these languages) -- and even for PHP work, I am not cheap. And, while I am of course a biased observer, I'd say I'm not low-skilled, either.
I generally agree with your technical criticisms of the language (I generated a bit of heat and light a few months ago with a blog post called "PHP is not an acceptable COBOL"), but I don't think your assertions about the economics are entirely correct. I don't think most companies choose PHP because they expect it will let them get cheap help -- I don't think most companies actually choose PHP. They end up with PHP for any number of reasons that don't have anything to do with long-term planning. (Also, if you were putting together a database-backed web site in the early 2000s, there's a very good chance you'd go with either ASP or PHP unless you had a lot of experience in web programming in another language. After you built up sufficient inertia, switching would be difficult.)
On the flip side, there are a lot of companies out here in Silicon Valley using Ruby on Rails because it fits very, very well into the niche you describe: take a bunch of Rails gems and learn just enough Ruby to hold it all together with spit and duct tape. If I were starting a company and wanting to hit the "low-skilled, cheap niche," the only downside to choosing Rails is that low-skilled Rails programmers frequently don't recognize that they're low-skilled, because the mere fact that they've chosen Rails makes them think they're definitionally awesome.
(N.B.: I like Rails a lot, but gosh, it's attitudinal.)
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.
"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.
I don't even know why I am having this discussion:
To me the concept of a fun programming language does not make sense. Programming languages, frameworks, etc are tools and they suited for certain task. If you use the right tool for the right task programming is fun. PHP, however, is not the most productive tools for any (reasonably complex) task. This is just a fact. If you want to challenge that fact, give a concrete counter-example.
However, like I said before you can still be productive in PHP. I am still doing occasional programming in PHP and I don't hate it. I just wouldn't use it for a new project.
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.
> 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.
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'.
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?
>>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.
How is PHP's garbage collection for these kinds of things? Usually, it doesn't need to be that good as you can just release all the memory after a request is processed in the typical way PHP is used.
Anyone have experience running PHP-based daemons or things like that? If your React/NodePHP-application crashes on a 'Allowed memory size exhausted' every two days, it'll get old quick.
5.3 and 5.4 are a lot better, but I can't say I'd use them for long running daemons. Personally, I usually use Python daemons that spin up a PHP instance if they need.
I created a server-less distributed network composed by PHP daemons some years ago, it was really fun seeing them linking, automatically discovering new nodes and distributing a task among the available nodes.
We chose PHP because it was the only technology supported in the company, who didn't want to invest on consultancy, research, just do it now, you know.
It was fun, but eventually PHP bad memory management became the main issue, so we were restarting daemons that would crash at random times, often in the middle of some tasks, other times while idle.
Today, I would never create a new project like that using PHP, it doesn't make sense. PHP is great for templating, scripting, and there are some nice frameworks for the classic web applications. However each language has some limitations, an engineer should know much better than that.
For some these php-but-like-node.js projects are abominations but there are a few reasonable use cases.
Of course the vast majority of php and the php 'class library' isn't appropriate for this programming model but neither was most of the existing js corpus before people built an ecosystem around node.js.
Actually, a surprising amount of JS code was already built around event-driven IO. It took a remarkably small amount of work to get YUI3 running on node, for example.
It should not be surprising that this can be done in php.
The libevent extension for event driven non-blocking I/O has been added some time ago. Together with many nice new features since PHP 5.3, including improved garbage collection and speed improvements, it naturally follows that php will be used for these things.
Btw, the libevent extension is really fantastic. If you're doing server programming, take a look at it, it will turbo-charge your server http://php.net/manual/en/book.libevent.php
Perhaps php lost some if its sexiness, but it's still rapidly evolving and improving.
To say this is a port of Node is to misunderstand 99% of what node is. In fact i dont really understand why you even relate this to node at all and why you use the node logo. Call it evented php or or a port of Tornado or something but its not node. If you want to learn what node is listen to Nodeup. Its an awesome podcast with core node people in it that talk about what node is and why it is what it is and why javascript is so integral to it.
There are a lot of reasons why people coming back to php. The main is its a language for 'getting things done' in the real sense. A lot of languages claim that in their own way. But in my experience nothing comes close to Php and Perl in the raw power, freedom and ultra fast pace of development they offer.
The other neighboring competitors of Php, namely Python and Ruby are in the web development market with the help of frameworks. I have yet to see a serious programming shop that would bet its billion dollar business on frameworks built by others. Small libraries I can understand. But building the spirit of your business and betting its survival on a Frameworks is just out of the question.
Php is the DSL for the web. And it does its job far too well. It can be learned quickly and you can build things quickly with it. Its installed everywhere, you can get cheap hosting. Tons of document and help available.
>From when was that any criteria for success? Worse is better won a long back. Fighting that has proven to be futile.
No, it hasn't. Pragmatism won over theoretical grounds. And there are very many pragmatic reasons to prefer PHP for certain projects. No one is arguing against that.
But, with legacy and a changing market, some of those pragmatic choices come back to bite you.
There are many ways to combat this. One can evolve the language, for example. This has worked better for some languages (Javascript comes to mind) that share some of design flaws in PHP, than it has for PHP itself.
What I am arguing about, is that, we as an industry, as a community, as a profession, we shouldn't be aiming for a future where PHP is still dominant, any more than we should be aiming for a future where horses are our dominant means of transportation.
Now, maybe we can shoehorn modern features into PHP. It has been tried with PHP4 and PHP5.
But for what reason? There isn't any decent implementation of PHP (performance and stability wise). Other syntaxes aren't that hard to get accustomed to. The algorithmic complexity of core operations has changed between versions. It's not like there is any important code written in PHP, that must survive some transition, like there is with C.
Is it just to keep those on board, with no academic training, who only know PHP? If they were capable of learning PHP by themselves, would other languages really be that hard for them to use (or abuse)?
> But building the spirit of your business and betting its survival on a Frameworks is just out of the question.
People building stuff in PHP use frameworks as standard too, even if it's one they built themselves.
I've recently converted a high traffic personal project from PHP to Python with no impact in performance. I also didn't feel like I was being slowed down by Python or Flask.
Rackspace uses Django, Twisted, and Node for basically all development work. It would be nuts to not use frameworks. Do you also lament that companies have to build their business around operating systems?
I think I can shed light on what being a "DSL for the web" means.
1. PHP has built-in templating in that it's a language that gets embedded within other text files. If you go with PHP, you don't have to decide how you're going to output your content into your front-end design. So, PHP (as a language) has made the decision on templating much in the way that frameworks like Rails and Django make that decision for Ruby and Python. And it's possible to override that decision in any of those frameworks and even PHP has alternative templating engines, but it provides a built-in default decision.
2. PHP puts many useful things into global variables. One can debate the merits of this (and I'm not here to do that), but when you're new to things and can be told "anything in that form will be available in $_REQUEST['var_name']," that can get you off the ground fast - much in the same way that params[:var_name] does in Rails.
3. PHP provides built-in "routing". Heck, it's files on your filesystem. You know how a static site works? Great! You know how PHP works (in terms of routing) as well. I appreciate having reversible routers, but one can see how PHP's approach is simple, especially for new users who might have experience with static sites.
I could go on, but it would basically be re-stating the same concept. PHP as a language includes many micro-framework features in the language itself and they're usually implemented in a simple way (even if one argues that it's not an ideal way for long-term maintainability). It gets people off the ground running fast and because its micro-framework-like capabilities are widely used, it's easy to google for information.
I don't program in PHP much, but I can understand why it could be called a "DSL for the web". It has many of the things that users grab a framework to handle built into the language. I personally much prefer to work on a site in a framework in Python, Ruby, C#, or Java, but PHP's thin layer of framework tools built into the language is very easy to understand and fast to learn.
Let me add my 2 cents. I do a lot of work PHP and when I want to do web stuff it's the path of least resistance. Other languages are certainly better but they're just not better enough to get over that hump. I'm still maintaining lots of PHP code and I only have so much brain space to dedicate to languages/frameworks for exactly the same task.
I do some work in C# now but for many reasons I don't want to do web with .NET.
I've done significant work in C, C++, Perl, C#, over the years. If my brain was wiped clean of all knowledge of PHP, I'd probably end up doing most work in Python.
Personally, I strongly dislike PHP and yet I still choose it for new projects sometimes. The main reasons? Being able to use `<?php ... ?>` blocks inline with HTML, and not having to add any boilerplate import statements just to get to basic CGI functionality. Such small trivial features, but they provide enough pain relief that they're sometimes worth it.
True, these hello world benchmarks are not indicative of real world performance, but suspect React would be significantly slower than node.js at a hello world showdown.
I think it's not a joke. look at the source code on github.
But I can't understand this elitism. Programming language choice must not be a cult. Anyone should be free whatever language they like to use whatever they want to do.
So bringing something good or seemingly good to any ecosystem should not get bad responses. They are trying to combine two worlds into a "new choice". Let them do even if yo do not like it. Nobody asks you to praise but just don't give uninformative bad responses.
As a community, as an industry, as an ecosystem, trying to move forward and leaving past mistakes is a good thing.
Our doctors no longer use voodoo dolls. They've moved on. And nobody with any relevant educational background would promote much of phps language design. We've moved on.
Unfortunately, PHP lives on as well, as some kind of eternal september of web development.
Nobody with any relevant industry experience would overstate the important of language design.
I've used many languages in my 25+ years in software development, and I've seen very little relation between language and either overall quality or simply getting stuff done.
I have however observed a strong negative relationship between that and people bitching about their and other people's tools.
I think it's just a matter of where you are on the curve.
Basing a new project on Node.JS may be premature and not a wise choice. You may be too much ahead of the curve, and up to the point where more traditional tools provide a much more pragmatic advantage mostly related to their ecosystem.
But nobody is writing their new website in C or ASM, or think that that is any more productive than using a more modern tool.
So, there is a movement, and that movement itself is towards better language design. The question is, where on the wave, should you be.
To argue, that any innovation in language ever, was always for the worst, is something reality and likely your own preferences directly contradict.
>I have however observed a strong negative relationship between that and people bitching about their and other people's tools.
I'm not trying to bitch. I'm not trying to argue that if all you want is a blog, that PHP is not one of the more pragmatical (get it done) approaches.
But that's not what this Node.PHP is targetting for. It's PHP rearing it's head again, at the tip of the wave. And when that happens, shouldn't we all just come out and say 'burn it to the ground?'
But that's not what this Node.PHP is targetting for. It's PHP rearing it's head again, at the tip of the wave. And when that happens, shouldn't we all just come out and say 'burn it to the ground?'
But why? What harm does it give you to have another incarnation of PHP? Does a kitten die if someone writes any loc with php?
If so why don't you go after Facebook and damn their hard work on HipHop? Why do so many engineers still work on PHP at Zend? please let it go.
You may not like it. If so *you can just stop using it".
This is some kind of saying:
"I don't like latin, so why on earth people still writing books on it? Why even they teach it at schools? Why do doctors still practice and learn it somehow? Just let it go die?"
Which ecosystems actually get the love, impacts us all. That's why people are always so invested when it comes to topics like this: they are literally, financially, emotionally, technically invested in their choice. And if some other solutions gets more popular, their investement will loose it's worth.
>You may not like it. If so *you can just stop using it".
Or, you know, start a conversation, and maybe see, if I can convice other people, to also not like it. (or to have them convince me otherwise).
>"I don't like latin, so why on earth people still writing books on it? Why even they teach it at schools? Why do doctors still practice and learn it somehow? Just let it go die?"
Great example! I fully agree, that it in the long term it would be beneficial to just drop latin all together and perhaps standarize on a more accessible language. It would be cheaper for everyone. More funds to spend on actual usefull research, more time to actually spend studying the relevant and challenging aspects of that field.
It matters what an industry standarizes on. It matters what technologies are popular and which are not. And yes, we vote with our actual choice. We vote with our wallet. But it's not a bad idea to have these kind of discussion as a community.
It's too easy to just dismiss people as 'go use something else if you dont like it', because our field is very much a non-zero sum game.
Physicians use Latin for a reason. I believe they do not like to use it either. But they can not leave it back. It would mean throwing away hundreds of years study away.
In Turkey there is a hot topic about it. In 1928 with the order of Mustafa Kemal Atatürk we transitioned to use Latin alphabet instead of Arabic alphabet. It lead us to easier to reading and writing. And we got combined with European sciences and literature. But this caused a hole in our literature, science and in some more majors. We can't read any Arabic alphabet work nowadays. And this means hundreds and thousands of years of literature, physics and many more kinds of works are forgotten.
> Basing a new project on Node.JS may be premature and not a wise choice.
Maybe one year ago but now Node.js is mature: The feature development ended, npm is close to perfection and surpasses package managers of other languages. The ecosystem is rich and and important modules are very mature.
Node offers tons of innovative stuff at low costs like no other setup, to say it's premature and not a wise choice doesn't sound very informed.
The rather unique problem that PHP has is that it is almost as if it was designed with the primary goal of encouraging the programmer to shoot themselves in the foot.
Most PHP good practices revolve around defending yourself from language features, whereas Python good practices (for example) are mostly about making sure your code is readable and easy for someone else to follow.
Ultimately people will pick the language they have most experience with, but that's not always going to be the language best suited for the task.
PHP as a platform is not super slow. Have you ever visited shootout.alioth.debian.org? most of the time PHP performs better than ruby, python or perl. It's up to 3 times faster.
PHP doesn't have closure like JavaScript. JS accomplished language for evented approach. Because JS have got closure, cascaded scope and prototype chaing.
Hate to burst your bubble, but "how revolutionary node.js is" has very little to do with anything. For example, Vert.x is a formalization (albeit a good one) of Netty-based practices we've been using for years in the Java ecosystem--I've got a "Vert.x prototype" in my projects graveyard and it's been there for years. Pretty much the same idea, though with a lot less love poured into it.
Don't get me wrong, I like Vert.x's API quite a lot and it's why I'm looking at using it. But it's not really "new", it just has a nicer coat of paint. And claiming that node.js is "revolutionary" because of it is a fairly criminal disservice to the ridiculously smart people behind Netty, Mina, and similar projects that have been around for a long time.
Well, for starters the whole standard library is blocking, so are all the third-party libraries.
Then you have the fact that any good developer who knows PHP is also going to know enough Javascript to get by already.
The only reason I can think of for this to be a good idea is to allow you to use your existing PHP libraries in an evented system. React does not (and cannot) do this.
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.