Re: FW: [PHP-DEV] Function caching...

Björn Schotte wrote: > * Zeev Suraski wrote: > > The two issues do not contradict each other. Ease of use is usually the > > primary concern for enterprise users, since ease of use means short time to > > market. Okay. Enterprise users. Large, international businesses? Hundreds of servers, all operating on proprietary OS's and platforms, with extremely segmented departments and sub-divisions? PHP works just fine in that environment, interacting with discongruous servers, creating quick departmental applications, building easily maintained quick-and-dirty dynamic web pages, working as a common tool in a variety of of environments. > That's true, but where are your arguments for the fullfillment > of today's needs in big web applications that should be done > with PHP _because_ of it's ease of use? The ease of developing the most common kind of enterprise web project, departmental pages, the UI into an HR database, a UI into an inventory database, etc. The enterprise has many needs, and each need should be filled *as appropriate*. Should PHP be used to run NASDAQ's data exchange, or to schedule airline flight plans? Heck no. The *web* is not a good medium for such things. Should it be used for sending forms data from thousands of different users, via the web, to back-end servers? Of course, it's *great* for this. This is what most of the web apps are about, a medium for submitting, and retrieving, simple data. > > As I said numerous times today, hardware is cheap in comparison to > > manpower > These are two pairs of shoes. I know about a product, www.mainchat.de, > where one can build his own chat for free - they have >25.000 Chats > with more than 250.000 users where more than 1000 users are synchronously > online - 8 web servers, 4 DB servers and a PHP software load balancing > server. But as you see, they used some "dirty hacks" they didn't have > to do if we would have such nice things as Kristian wrote in his mail. Asynchronous web chats between 250K users is not a business application, or a standard enterprise application. It's a specialized niche, and it's most cetainly not an ideal PHP project. By the same token, PHP *could* be used to write slashdot, or iPrint.com, or a streaming media server... but in all cases, different languages have better features for this. Trying to make one script language work for all possible applications is doomed to failure, because the complexity of the language would quickly outweigh the benefits. > > and short development time, so performance comes in second. > That's not true. Please read Jakob Nielson on > www.useit.com. Performance is an issue that > _does_ _count_ today, especially for enterprise > users (look at my mail where I stated the contract > issues). As I've pointed out several times, anybody can design code poorly, and can code for PHP in a way which is _not_ suitable for its process model. This makes for slow running code. Just as possible is fast code, written *with PHP's design in mind*. But if you look at most applications written in, and for, the large enterprise market, they are *not* optimized for speed.... They are hacked together by different teams and coders who just want a quick toolkit to get the job done. Perl is the duct tape of the Unix world, not because it has so many speed optimizations, but because it can be *used* like duct tape, it can be applied quickly to make something work better, and hold together. This is not the same market as building a dedicated, single purpose, web server, for a massive .com application. Those .com app users will maximize their code for speed, and will avoid using code which slows them down, be it libraries, objects, or even disk drivers that run slower. They will spend more time on tuning, redesign, recoding, to make the server software more responsive. Massive Single Application != Most Enterprise Application Requirements > > >Mental note: and we should spread all over the world that > > >PHP (or: the developer's of PHP / Zend) is not interested > > >in doing evolution and filling the needs the web application > > >developer of TODAY has; instead, PHP should stagnate all over > > >and remain a script language that is only capable for small > > >web sites who are doing 08/15 things. > > That's utter bull. > Prove the contrary. They already have, in spades. Rather than building a horribly slow, complex OO language like Java, or a steep learning curve like C++ or webobjects, or the unreadable line noise of Perl, they've created an easy, efficient, open-source language, designed for web sites, that runs more shopping carts, guestbooks, mail forms, and web sites than most other web-specific application languages do. Why? Because it's fast and easy to write a guest book, mail form, or dynamic site content in, which is what most of the internet is using. This is where the coders start, before they need to *custom build* something that may require a different language, or highly optimized code.... be that code in PHP, C, Perl, Tcl, whatever. Once they are part of an app-specific build, their needs will be determined by the needs of the application. If the app requires rapid, constant, per-page, modification by less experienced coders, PHP is a better choice than WO. If you need a massive hit-count app, using an oracle server farm, and Tcl is a language you can use, aolserver is a great choice. If you are part of the 99.9% of server users that don't get 1000 hits a minute, PHP is a beautiful choice. Are they intersted in filling the needs of *all* web application developers "of TODAY"? I hope not. -Bop -- Personal: ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/ Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/ The opinions expressed in this email are not neccesarrily those of myself, my employers, or any of the other little voices in my head.