yea right.. i really want to keep my code base in 1 language, because that simplifies everything later on imo. you people, who are against the evolotion of php towards cloud computing, would force me to do mixed-languages projects or even rewrite large sections of my codebase if as i want, i keep my codebase in 1 language. maybe now you understand why i'm so pissed off with you know-it-alls. On Wed, Mar 24, 2010 at 1:04 PM, Peter Lind <peter.e.lind@xxxxxxxxx> wrote: > On 24 March 2010 11:53, Tommy Pham <tommyhp2@xxxxxxxxx> wrote: >> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen <per@xxxxxxxxxxxx> wrote: >>> Tommy Pham wrote: >>> >>>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen <per@xxxxxxxxxxxx> wrote: >>>>> Tommy Pham wrote: >>>>> >>>>>> What I find funny is that one of opponents of PHP threads earlier >>>>>> mentioned that how silly it would be to be using C in a web app. >>>>>> Now I hear people mentioning C when they need "productivity" or >>>>>> "speed"... >>>>>> >>>>> >>>>> I think I was the one to mention the latter, but as I started out >>>>> saying, and as others have said too, it's about the right tool for >>>>> the right job. When choosing a tool, there are a number of factors >>>>> to consider - developer productivity, available skills, future >>>>> maintenance, performance, scalability, portability, parallelism, >>>>> performance etcetera. >>>>> >>>> >>>> Funny you should mention all that. Let's say that you're longer with >>>> that company, either by direct employment or contract consultant. >>>> You've implemented C because you need 'thread'. Now your replacement >>>> comes in and has no clue about C even though your replacement is a PHP >>>> guru. How much headache is maintenance gonna be? Scalability? >>>> Portability? wow.... >>> >>> Who was the idi... who hired someone who wasn't suited for the job? >>> Tommy, that's a moot argument. You can't fit a square peg in a round >>> hole. >>> >>> >>> >>> -- >>> Per Jessen, Zürich (12.5°C) >>> >>> >> >> Suited for the job? You mean introduce more complexity to a problem >> that what could be avoided to begin with if PHP has thread support? >> hmmm.... > > Except, you already introduced complexity into the problem. You see, > working with threads is another requirement, whether it be done in PHP > or not. Hence, hiring the right guy is independent of whether you have > threads in PHP or not - your problem is no less nor no more complex > whether you do threading inside or outside PHP. You just assume that > adding thread support to PHP will solve the problem, but there's no > actual basis to believe this. > > >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > > -- > <hype> > WWW: http://plphp.dk / http://plind.dk > LinkedIn: http://www.linkedin.com/in/plind > Flickr: http://www.flickr.com/photos/fake51 > BeWelcome: Fake51 > Couchsurfing: Fake51 > </hype> > > -- > 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
