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 <rene7...@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 <stut...@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 <p...@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/ > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
