Well, since I was the one that started this shit-storm, I'll chime in for a minute... ;-) > 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 I'm sorry. I didn't realize PHP was designed for "beginers". You do realize that just b/c PHP would have threading in it, doesn't mean you actually have to use it right? My PHP has all sorts of other libraries in it that I don't use. > 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.... [And related] > Thanks for supporting PHP thread. Thus, it would be a lot easier for > any PHP guru to scale, make it portable, or integrate into other PHP > apps without having to juggle C, Ruby, Python... and whatever else is > out there... Amen. Case in point. I had a developer who wrote our back end in Ruby. It's nearly impossible to find an expert ruby developer. You can't swing a dead cat without hitting a Rails guy these days, but they don't know the nuts and bolts Ruby (we don't use Rails. We use PHP for the front end). > 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. Uh. Learning the concept of threads is TRIVIAL compared to learning an ENTIRE NEW LANGUAGE! Are you serious? Come on now guy. This argument is just contrived. > 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. Absolutely spot on. My company is standing still right now because we can't find a damn Ruby guy that can code to this level! Had PHP had threading, then we could have just used that for the back-end and front end. ...right tool for the job my ass. At a previous company I watched nearly the same thing happen. We were supposed to be sold for $25MM and when the due diligence came along and they saw we had written things in two languages (Ruby and PHP again actually, they declined on the last day and the company folded). They said it was too difficult to integrate into their software which used a third language. > You mentioned Facebook as an example of a popular > application. Are you aware that they only recently started > using their compiler in production, and that prior to that > they were happily running PHP to serve their front end > without ever complaining that it didn't support threading? > Even now, with hip-hop, individual requests are served in a > single thread, so the language itself still doesn't support > threading, and I don't hear them complaining that it's > costing them a fortune. Why? Because it's not. And if it was > they would have added it by now. You all think to shallow and narrow minded. You keep thinking in terms of using PHP as simply a web language. You need to think in terms of using it like Perl, Python, Ruby, Java, C/++, etc. Computers do a lot more than just spit out web pages these days. I know most of you seem to only think in terms of "the cloud" and other stupid technologies like that, but there's a great big world of computing that doesn't. There's no reason that PHP shouldn't be a viable language to use in those arenas either. > for some reason, which is still not clear to me, you nay-sayers refuse > to let a PROGRAMMING LANGUAGE (not a "hammer", not a "fishing boat") > evolve to stay useful, relevant even, in a changing market. > > and you're blatantly telling me to use a different kind of "hammer", > one that would force me to rewrite large sections of my existing > code-base, and one that i have told you i would find for many other > _valid_ reasons not optimal. Spot on again. I have maybe 12 YEARS of PHP expertise, knowledge, libraries, tools, code snippets, etc that are battle tested and hardened and improved constantly. Now I'd have to toss all that out just to write some things in a language that has threading -- something that is a given in most EVERY other language. > The database is still a bottleneck. Now instead of processing > one query > at a time for a PHP script, it's processing 3 because you want them > processed in parallel. Now the database is struggling with 3 times the > work to complete in the same amount of time. > > Threading hasn't helped that much here, you've just moved the > problem to an area which is already generally considered the bottleneck > in most applications. Not entirely true. You could have several slave databases in a pool and therefore each thread would connect to another slave (and BTW, each slave does NOT have to be a separate box either, just instances on one box or VMs). Thereby retaining your parallelism and speed. > portability? Now that you mention cross platform threading, do you > think you can take the MySQL compiled for linux and make it work under > BSD withouth BSD's linux binaries compatibility, nevermind Windows? > Have you looked at the source of PHP? For whatever OS PHP compiles > for, it uses the header library pertaining to that OS. So if I want > to implement thread solution similar to Per's solution, I'd have to be > an expert at Windows, Linux, and *BSD just to make my PHP open source > project to be readily acceptable to the world. I'll pass on that. Don?t give a shit. LAMP is the only real setup out there. And I'm perfectly happy with a "PHP --with-threads-on-linux-only" option. It's trivial to setup a LAMP box if you need threads. I don't care if it works on OSX, BSD, Windows or anything else. That's not elitist, that's just quashing this argument with a viable solution. Just as people code their web pages to work on IE and Firefox and don't worry about the other fringe browsers, so it could follow that the threading only works on PHP for Linux. There are currently several functions and differences in PHP now that "only work on Windows" or "only works on Unix". Nobody's complaining too loudly that I'm aware of. And, to those that believe throwing more hardware at the problem is the solution, you must work for Microsoft or something as that's their philosophy too. [a] think about the effect on the environment that has (not only in energy, but also landfill E-waste), [b] think of how much it costs to put a rack in data-center. Space is limited you know. [c] why wouldn't you squeeze every microsecond of performance you can from existing hardware before spending wasted money, time and resources on new hardware? You either work for a huge mega-corp where they're used to blowing wads of cache, or you are have not worked for a startup where every single dollar is someone else's and they want to know how and why you're spending it. P.S. I HATE bottom posting. WTF do I have to scroll all the way down past hundreds of useless lines just to read a "me too" or some other comment. If it's at the top, I can simply just keep moving from header to header in Outlook (or your email GUI of choice). DELETE as I go. Easy. Simple. Efficient. ÐÆ5ÏÐ http://daevid.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
