On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas <stut...@gmail.com> wrote:
> On 24 Mar 2010, at 09:36, Rene Veerman wrote:
>> unless the actual php development team would like to weigh in on this
>> matter of course.
>> yes, i do consider it that important.
>> these nay-sayers usually also lobby the dev-team to such extent that
>> these features would actually not make it into php.
> Frankly I don't give a crap whether threading is supported in PHP, it does
> everything I need it to do. If I need threading I use a language that
> supports it, like Python or C++.
> I love the way you call us nay-sayers like it's supposed to be an insult. I
> follow the KISS principle to the nth, and as such threading in PHP doesn't
> make a lot of sense to me. I'm yet to come across a problem I couldn't solve
> with pure PHP, but when the need arises I have no issue mixing in a little
> C++, Python, Ruby, or whatever, to meet my performance and scalability goals.
> I go to the mountain, I don't sit there complaining that the mountain ain't
> moving in my direction!
> My opinion, and that of most others who've weighed in, is that you're almost
> certainly looking at the problem from the wrong angle. What you haven't done
> is explicitly explain why you want threading to be supported. Give us a real
> example of why you think it should be supported and I guarantee we can come
> up with a way to get you what you want without requiring massive changes to
> the core of your chosen tool. And if we can't then you may actually convince
> us that threading would be a valuable feature to have available.
I did give a real life example, ie e-commerce site mentioned earlier.
Amazon has the similar features of my example except they have about
30 million products without (i18n). Their I18n is different web
server & db & site layout which is completely different from my
example. Setting I18n aside, having the same features as my example
with about 30 million products to response in about 3 seconds is very
good. Even though my example only have about 750,000 products, the
translations for the requested languages makes it into 750,000 * 6 =
4,500,000 rows of product descriptions. This is e-commerce site not a
data warehouse/mining. What would happen then if the site has over
20,000,000 product skus with similar language translations for the
descriptions? 20,000,000 * 6 = ... big number to me...
> You mentioned Facebook as an example of a popular application. Are you aware
> that they only recently started using their compiler in production, and that
> prior to that they were happily running PHP to serve their front end without
> ever complaining that it didn't support threading? Even now, with hip-hop,
> individual requests are served in a single thread, so the language itself
> still doesn't support threading, and I don't hear them complaining that it's
> costing them a fortune. Why? Because it's not. And if it was they would have
> added it by now.
> One final thing... if threading is this important to you, then I'm sure there
> are a number of developers who would happily add it in a fork of the core for
> suitable compensation. Once implemented it's possible the internals team
> would accept it for addition to the official version. If you really believe
> it has the potential to save you a butt-load of cash, the economics of paying
> for it should stack up.
> Oh, and feel free to escalate this to anyone you please. Nobody cares.
> Threading has been discussed before, both on this list and on internals
> (Google can tell you all about it), and every time it's been dismissed
> because the cost-benefit calculations just don't add up.
>> On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman <rene7...@gmail.com> wrote:
>>> php is not a hammer, its a programming language.
> And bravo on the metaphor appreciation failure. Love it!
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php