On Wed, Mar 24, 2010 at 10:19 PM, Ashley Sheridan <a...@ashleysheridan.co.uk>wrote:
> On Wed, 2010-03-24 at 22:15 +0200, Rene Veerman wrote: > > On Wed, Mar 24, 2010 at 10:05 PM, Ashley Sheridan > <a...@ashleysheridan.co.uk>wrote: > > > > > > > So you're basically saying that you'd discount anyone who opposes you > > purely because you think you know best? > > > > Nice attitude. > > > > I ain't saying that at all, nor did i intend to imply it. > > In fact it's the anti-threading/shared-mem camp that thinks they know > everything best with their instistance that "throw more hardware at it, more > sql servers, more programming languages in a single project" will solve all > software design / growth problems with enough efficiency. > > They're offering the alternative. You keep disagreeing with their viewpoint > because you seem to think you know best on this matter and won't even > concede on a point. > they're offering an alternative that would not solve the use-case i could think of within 1 day.. and they also say 'add more hardware' which means more overhead of every kind, resulting in wasteful business practices. > In this case, you still haven't given me any other reason to oppose the > evolution of php with the market trend > > Do you have any proof of this 'market trend'? I suggested a vote, but you > 'nay-sayed' it on the basis that you'd lose to people who couldn't possibly > know as much as you do. > yes, twitter. facebook. the fact that a graphics upgrade would likely increase business for the first ones on that popularity level to implement it. that's the proof i have for the market trend. oh, and the fact "cloud computing" is becoming more and more of a buzzword in the industry. > > I wouldn't say I belonged to any particular camp at the start of this > thread, but now, having read what my betters have said, I'm inclined to > agree that threading isn't the magic wand that you seem to think it is. I > personally see one of the largest sites in the world running on PHP without > needing threading and without insulting half the list to attempt to get it. > > you haven't offered me any description at all of how i'd solve the large-scale realtime-web-app with existing techniques. and if i explain why i'd need the features we've discussed, you dismiss it by accepting a generalized "that can be solved with more sql servers" answer that is admitted to increase costs in every department, including energy consumption. on a non-linear scale btw.
