Will PHP ever "grow up" and have threading?
in [General]
|
From: Per Jessen on 24 Mar 2010 05:23 Rene Veerman wrote: > what you're suggesting is highly intrusive in my work-style, one that= > you're not affected by at all. Hmm, you're the one suggesting a change, I'm suggesting no change. How= can "no change" be intrusive?=20 > in fact if you make things more difficult for me, i have less time to= > release opensource code of my own. Well, we can't have that, so how about we stick to "no change", thereby= not making anything more difficult for you. It will remain exactly as difficult as it is today. --=20 Per Jessen, Z=C3=BCrich (10.4=C2=B0C)
From: "Arno Kuhl" on 24 Mar 2010 05:24 If you added threading to the bag of tricks it already has, you're getting into areas that make it more difficult to pick up for beginners (and that's not to mention the technical elements involved in actually adding threading to PHP) Currently the only other 'easy' language I know for beginners is ColdFusion, and that's just horrible. You wouldn't want to be responsible for sending the newbies down that path would you?! :p Thanks, Ash http://www.ashleysheridan.co.uk ====================================== That's not a good argument against implementing threading, regardless of the technical issues involved in making it work. There are plenty of more advanced areas of php that beginners stay clear of. Just because threading is available doesn't mean it will automatically be used or even considered in most projects. I wrote C code for years in a large fairly complex banking front-office system and only found a very few occasions where threading was required to get the job done. In the majority of C and C++ code you find very few examples of threading, either because it's not required (99.9% of the time) or the coder didn't feel comfortable using it and found another way to achieve the result. In the few occasions where I did use threading I would say that most the time there was no other way of achieving the required result. But the issues you need to solve with C are very different to the issues you need to solve with php. I've spent more than 8 years coding php and I haven't ever hit a brick wall because of the lack of threading, but of course every project is different and I'm sure there are situations out there where trying to work around the lack of threading can cause major hassles. But as others have pointed out you use the right tools for the job, and if php doesn't have what is required then use something else. Cheers Arno
From: Per Jessen on 24 Mar 2010 05:30 Rene Veerman wrote: >>> b) i will aim for all possible decreases in development time and >>> operating costs during, not only in the grow phase but also in hard= >>> economic times. any business person knows why. >> >> Given that the lifetime effort (=3Dcost) of any software project is >> divided into 25% development and 75% maintenance, you really ought t= o >> focus on the latter. =C2=A0If you want more performance at a minimal= cost, >> surely you should opt to write in a compiled language where you'll >> get far more bang for the buck. >> > zend? facebook compiler? C, then assembler. C for productivity, assembler for raw speed. PHP for prototyping and web frontends (to which it is very well suited IMHO). (assembler is usually bad for both productivity and maintenance, but if speed is paramount, well). --=20 Per Jessen, Z=C3=BCrich (10.4=C2=B0C)
From: Rene Veerman on 24 Mar 2010 05:31 php is not a hammer, its a programming language. one that i feel needs to stay ahead of the computing trend if it is to be considered a language for large scale applications. but you nay-sayers here have convinced me; i'll be shopping for another language with which to serve my applications and the weboutput they produce.. thanks for opening my eyes and telling to abandon ship in time. On Wed, Mar 24, 2010 at 11:22 AM, Stuart Dallas <stuttle(a)gmail.com> wrote: > Heh, you guys are funny! > > On 24 Mar 2010, at 08:58, Rene Veerman wrote: > >> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen <per(a)computer.org> wrote: >>> Rene Veerman wrote: >>> >>>> popular : facebook youtube etc >>>> >>> >>> Rene, I must be missing something here. That sort of size implies >>> millions in advertising revenue, so why are we discussing how much >>> performance we can squeeze out of a single box? I mean, I'm all for >>> efficient use of system resources, but if I have a semi-scalable >>> application, it's a lot easier just getting another box than trying to >>> change the implementation language. OTOH, if my design is not >>> scalable, it's probably also easier to redo it than trying to change >>> the implementation language. >> >> again: >> a) you're determining the contents of my toolset, without it affecting >> you at all. the way you want it php will degrade into a toy language. > > And how exactly are you defining a toy language? If you want features like threading, why not switch to a language that already supports it? > >> b) i will aim for all possible decreases in development time and >> operating costs during, not only in the grow phase but also in hard >> economic times. any business person knows why. > > Yup, this is very good practice, but deciding that one particular tool is the only option is a fatal business decision. Use the right tool for the job! > > What you're trying to do here is akin to taking a hammer and whittling a screwdriver in to the handle. It's ridiculously inefficient, and imo, pretty stupid. > >>>> and you're still trying to impose a toolset on me. >>> >>> I didn't think I was - you're the one who seem to be fixed on PHP as the >>> only solution, and advocating that it be enhanced to suit your >>> purposes. >> >> no, php is just my toolset of choice, and i think it should grow with >> the times and support threading and shared memory. >> maybe even a few cool features to enable use-as-a-cloud. > > PHP is a hammer, and a bloody good one at that, but you seem to want it to be a tool shed. Accept that it's a hammer, go visit a DIY store, find the right tool for the job and get on with your life! > > The fact is that even if we all agree that PHP needs threading, and one or more people start working on putting it into the core, it will likely be many months before you see any sight of a working version, and even longer before you see a stable release. > > -Stuart > > -- > http://stut.net/
From: Rene Veerman on 24 Mar 2010 05:36
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. On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman <rene7705(a)gmail.com> wrote: > php is not a hammer, its a programming language. > > one that i feel needs to stay ahead of the computing trend if it is to > be considered a language for large scale applications. > > but you nay-sayers here have convinced me; i'll be shopping for > another language with which to serve my applications and the weboutput > they produce.. > > thanks for opening my eyes and telling to abandon ship in time. > > > On Wed, Mar 24, 2010 at 11:22 AM, Stuart Dallas <stuttle(a)gmail.com> wrote: >> Heh, you guys are funny! >> >> On 24 Mar 2010, at 08:58, Rene Veerman wrote: >> >>> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen <per(a)computer.org> wrote: >>>> Rene Veerman wrote: >>>> >>>>> popular : facebook youtube etc >>>>> >>>> >>>> Rene, I must be missing something here. That sort of size implies >>>> millions in advertising revenue, so why are we discussing how much >>>> performance we can squeeze out of a single box? I mean, I'm all for >>>> efficient use of system resources, but if I have a semi-scalable >>>> application, it's a lot easier just getting another box than trying to >>>> change the implementation language. OTOH, if my design is not >>>> scalable, it's probably also easier to redo it than trying to change >>>> the implementation language. >>> >>> again: >>> a) you're determining the contents of my toolset, without it affecting >>> you at all. the way you want it php will degrade into a toy language. >> >> And how exactly are you defining a toy language? If you want features like threading, why not switch to a language that already supports it? >> >>> b) i will aim for all possible decreases in development time and >>> operating costs during, not only in the grow phase but also in hard >>> economic times. any business person knows why. >> >> Yup, this is very good practice, but deciding that one particular tool is the only option is a fatal business decision. Use the right tool for the job! >> >> What you're trying to do here is akin to taking a hammer and whittling a screwdriver in to the handle. It's ridiculously inefficient, and imo, pretty stupid. >> >>>>> and you're still trying to impose a toolset on me. >>>> >>>> I didn't think I was - you're the one who seem to be fixed on PHP as the >>>> only solution, and advocating that it be enhanced to suit your >>>> purposes. >>> >>> no, php is just my toolset of choice, and i think it should grow with >>> the times and support threading and shared memory. >>> maybe even a few cool features to enable use-as-a-cloud. >> >> PHP is a hammer, and a bloody good one at that, but you seem to want it to be a tool shed. Accept that it's a hammer, go visit a DIY store, find the right tool for the job and get on with your life! >> >> The fact is that even if we all agree that PHP needs threading, and one or more people start working on putting it into the core, it will likely be many months before you see any sight of a working version, and even longer before you see a stable release. >> >> -Stuart >> >> -- >> http://stut.net/ > |