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 <> wrote:
> On 24 March 2010 11:53, Tommy Pham <> wrote:
>> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen <> wrote:
>>> Tommy Pham wrote:
>>>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen <> 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 (
>> To unsubscribe, visit:
> --
> <hype>
> WWW: /
> LinkedIn:
> Flickr:
> BeWelcome: Fake51
> Couchsurfing: Fake51
> </hype>
> --
> PHP General Mailing List (
> To unsubscribe, visit:

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to