Slashdot Mirror

← Back to Stories (view on slashdot.org)

Yahoo Moving to PHP

Posted by michael on from the herding-cats dept.

Erek Dyskant writes "Yahoo has decided to switch from a proprietary system written in C/C++ to PHP for their backend scripting. Here's the notes from a presentation by a Yahoo engineer at PHP Con 2002."

54 of 733 comments (clear)

  1. Dangers by briggsb · · Score: 5, Funny

    I hope the developers at Yahoo! understand fully the dangers of using PHP.

  2. It makes sense ... by SuperDuG · · Score: 5, Insightful
    PHP has begun to prove itself as a very mission-critical, cross-platform, well versed, and stable scripting language. For what Yahoo does and for the optimizations that have come in newer versions of php this makes a whole lot of sense. If yahoo plans on using a mod_php with apache 2.0 then I can see them even getting more performance gains. There's no way to tell as I've never actually seen the system they use currently.

    Obviously open source DOES apply to the corperate world.

    --
    Ignore the "p2p is theft" trolls, they're just uninformed
    1. Re:It makes sense ... by rseuhs · · Score: 5, Insightful
      Where have you been in the last 5 years?

      If you say that open source has a place in corporate webservers, I'd say that's a massive understatement.

      Open Source (Apache and PHP) is the standard in the webserver space already and is gaining more marketshare every year.

      Right now, only NBM (nothing but Microsoft) users and legacy systems run IIS. It doesn't offer anything valuable, except customer lock-in. (which is very valuable, but only for Microsoft)

    2. Re:It makes sense ... by jonbrewer · · Score: 5, Informative

      Right now, only NBM (nothing but Microsoft) users and legacy systems run IIS. It doesn't offer anything valuable, except customer lock-in. (which is very valuable, but only for Microsoft)

      There's no way you can back that statement up. Corporations generally have a few outward-facing web servers, and yes, these are most likely running apache, but the vast majority of Intranet web servers are still IIS. After that you'll see Lotus Domino and iPlanet, and then Apache.

      (This is from my experience with large corporations, though the IT rags such as Information Week and Network Computing back me up.)

      IIS is the standard for Intranet web servers for a reason - it's standard. It comes with every NT server. It's easy, and setup/administration hasn't changed in years. Any clown with knowledge of Windows can make it work, and it is stable and reliable.

      In the last 7.5 years I have administered just about every popular web server written (including NCSA HTTPd, WebStar, and IIS on NT 3.51 back in the day). Of all of them, I've found IIS the easiest to work with. Coupled with Win2k workstation on the desktop, it's almost fun to administer them with MMC and watch their behavior with PerfMon.

      The reason I deploy mainly IIS servers is that I can order a server from the IT department with a standard Win2k build and have secure applications (with access control) running on it within minutes of taking delivery of the box. Try that with a Solaris, Irix, or Linux box, I dare you. (Yes, I currently deploy and manage Apache on Solaris, Irix, and Linux, just not as often as IIS on NT/Win2k.)

      Sure Open Source has a place in corporate webservers. That place just isn't big, and won't be until Apache is easy to configure and integrates seamlessly with Windows NT security. When an idiot with an IT degree from the local community college can integrate Apache on Unix with a corporate network and can authenticate users and implement access controls without opening a book, then Open Source will have arrived in the corporation, and will start to eat into IIS market share of the Intranet. Until then, it'll be fringe, relegated to use on big systems with unix sysadmins doing the implementation.

  3. Maintence must be easier by papasui · · Score: 5, Insightful

    I'm sure it must be easier to find someone who knows PHP then it is to find someone who does cgi-bin c/c++ to maintain their sites. We use PHP/Asp for many of our internal applications we use for monitoring network systems and integrate it with MySQL. Works very well.

    1. Re:Maintence must be easier by dimator · · Score: 5, Interesting

      I can't for the life of me figure out why so many people pick it for web apps.

      I guess everyone is smoking crack except you. Seriously, why does MySQL get all this smack talk? I use it because its easy, every language I know of has bindings for it, its fast enough, and its stable. PLEASE spare me your "But XXX does that too, not to mention bla bla bla!" No, I won't switch, because I learned MySQL first (as I'm sure many others have) and so far it hasn't let me down.

      --
      python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
    2. Re:Maintence must be easier by leviramsey · · Score: 5, Informative

      MySQL is faster in really only one particular case: lots of SELECTs with few UPDATE/INSERT/DELETEs. Many applications have orders of magnitude more SELECTs than other queries (I'd guesstimate that Slashdot books at least two orders of magnitude more SELECTs). Nothing beats MySQL in that environment, and there are a lot of apps where that's all that's needed (think CMS's and other such things).

  4. Seems like a silly move... by FortKnox · · Score: 4, Interesting

    Going from something speedy and efficient to PHP.

    Why not switch to J2EE? Obviously, this is an extremely large enterprise web-app. They could take full advantage of all EJBs and Webapp clustering. I just don't see why you'd use PHP, when J2EE has so much more of an advantage on an enterprise level.

    On reading the slide show, the reason not to pick J2EE:
    you can't really use Java w/o threads
    Threads support on FreeBSD is not great

    Is this really a bad thing?
    Especially for the advantages EJBs give you??

    --
    Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
    1. Re:Seems like a silly move... by photon317 · · Score: 5, Insightful


      Eep, why J2EE? It's slow, it's a memory hog, it doesn't deliver on the write-once-run-anywhere promise of Java because of the vendors' differences. Perhaps most importantly for them, you really can't use Java w/o threads, and thread support on FreeBSD is not great. Read that over again. That means that Java doesn't scale well for you if your OS's thread don't scale well for you. If you're running FreeBSD, then that's the case, which further limits Java's absymal performance.

      --
      11*43+456^2
    2. Re:Seems like a silly move... by TheTomcat · · Score: 5, Insightful

      isn't going to give any type of boost over a proprietary C/C++ app

      It wasn't a proprietary C/C++ app, it was a proprietary C/C++ scripting language.

      Performace should be same or better, if I understand correctly.

      S

    3. Re:Seems like a silly move... by Vaulter · · Score: 5, Informative


      Because Yahoo is one of the fastest sites on the 'net.

      EJB's are great, don't get me wrong. They are great for handling database abstractions with zero tolerance for errors. But they are not fast, and horrible overkill for a site like Yahoo. All that abstraction and IIOP communication kills performance. Which is why shops that have large EJB applications tend to run them on heavy duty sun hardware. Not i386 boxes running FreeBSD.

      --
      I don't have a sig...Do you??
    4. Re:Seems like a silly move... by glwtta · · Score: 5, Interesting
      Hm, if they are rewriting their entire app, wouldn't a move from FreeBSD to some other UNIX(-like thing) be small in comparison?

      I mean seriously, I'd love to hear the pros and cons of the "Moving our stuff off of FreeBSD" vs. "Having to maintain everything in PHP instead of J2EE" discussion.

      --
      sic transit gloria mundi
    5. Re:Seems like a silly move... by sporty · · Score: 4, Informative

      Ug, as a prior php developer, who worked on enterprise level apps, i'd pray for them. PHP has it's unique problems once you have a large code base. You are more likely to require two modules in php that won't play well toegether or get errors in php itself. Php didn't like gnome-xml and ssl together at one point for example. I've had includes just die randomly when the include_once tree got too large. It'd die on a variable assignment.. strange shit.

      --

      -
      ping -f 255.255.255.255 # if only

    6. Re:Seems like a silly move... by FortKnox · · Score: 5, Interesting

      Because J2EE is slow to develop in

      I'd argue that if you use 2.0 EJBs and JBuilder, I could code just as fast as any regular language, but scripting languages are easier to slap code into.
      Now, good scripted PHP vs good abstracted OO Java. To code from scratch, PHP'ers could lay down code quicker. Java is easier to maintain and easier to add onto (if properly architected). In the end, I'd call it even ground.

      slow at executing

      Java 1 was slow. That was like 5 years ago. Go download JBuilder and run it. Made in C++, right? BUZZT! Its Java. Java has come a long way.

      J2EE is beautiful in theory, but not in practice

      Well, my job is a J2EE developer, so I guess the complex, enterprise level application that is running currently in front of me isn't java, cause it isn't beautiful in practice.

      Anyone with that only on their resume will have to shape up the next years, when PHB's stop buying that particular buzzword and move on to the next.

      Go look at monster. J2EE is one of the few languages that people have been hiring in throughout the recession. That doesn't sound like something PHB's are gonna just stop hiring.

      --
      Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
    7. Re:Seems like a silly move... by pthisis · · Score: 4, Insightful

      Standard Java stereotype. Java was slow a long time ago, not today. That gross asumption alone should get you modded down.

      Standard Java propoganda. The Java language is plenty fast (relative to the other solutions discussed), but most of the I/O libraries are still hideously slow. Ignoring that completely should get you modded down.

      Even a fairly slow computational language like Python drops Java out of the running for typical high-volume web site usage, simply because of I/O problems. Java is quite suitable in low-volume settings with stiff transactional requirements or heavy computational requirements--any setting where high I/O costs are amortized by several-order-of-magnitude higher page generation costs. It's a bad choice for a very high-volume site which basically wants to paste several database sources together into a template and shove it out the pipe; Yahoo! falls pretty squarely into that camp for most of its pages.

      They also have many components written in various domain-appropriate languages or that they don't want to rewrite for whatever reason; JNI is still pretty heavyweight, and if you have a lot of language interop requirements Java isn't a great choice (though if you're willing to sacrifice some JVM portability this can often be worked around, especially if the other benefits of Java outweigh the cost of implementation).

      On top of that, using EJB/J2EE will kill performance even more, which means that actually getting the feature benefits of Java requires handing away even more performance.

      All that's without even addressing the "requires tons of threads" problem; multiplexed I/O is pretty new to Java, and there's no good multiprocess API. Both of those are major problems, though hopefully multiplexed I/O will mature quickly. But until there's a good multiprocess API, Java's going to be unsuitable for a number of applications (and sticking to a platform-independent mentality instead of a platform-agnostic mentality makes implementing an efficient multiprocess API very difficult indeed).

      Worst of all are the memory issues, but those are well-known enough not to be worth rehashing.

      Sumner

      --
      rage, rage against the dying of the light
    8. Re:Seems like a silly move... by jallen02 · · Score: 4, Insightful

      You care to back up any of the claims your making? I have seen J2EE in production environments deployed with great success. There is nothing inherently slow about J2EE in general. "Java's abysmal performance"? In what context is Java's performance abysmal. I won't contest that for a number of tasks it is not optimal, for server application programming tasks it really shines.

      I just don't buy outright arguments like that at face value. It is *NOT* well understood or believed that what you state is true among any large groups of professional developers with proven experience deploying J2EE apps. Proof please.

      Trust me, I love PHP. I wrote a book on PHP and think it can do great things.. but for enterprise level applications and for quite a few tasks it just isn't there.

      Jeremy

    9. Re:Seems like a silly move... by lateefj · · Score: 4, Interesting

      J2EE or PHP?
      I had to make this decision myself. I would like to share some of the reasons I chose J2EE over PHP.
      J2EE is a specifaction that is implemented by Java. PHP is a scripting language that runs on web servers. One of the problems I came up against was writing PHP was fast but as soon as the application left the modules that where included by PHP you would have to write them in C/C++ and compile them into PHP. This was NOT maintable and C/C++ are not RAD (Rapid Application Development). Basically PHP is limited to the running inside of Apache which for a small site is not much of a limitation but all of the website I have worked this was a huge limitation. For example there is no way to schedule a PHP script to run without outside software. Java is a langauge that provides a lot of different ways to schedule events.

      PHP has a couple major database interface problems that Java does not. One the database abstraction exist only by extention such as PEAR. Persitant connections create a connection for every Webserver process. So if I have n number of connections to the webserver I have n number of database connections. Since the query took a lot less time then it does to send the web page back to the client. For a small site this is no problem because there are very few connections at a time. But when you start dealing with multiple servers and large numbers of user connecting at the same time the database server soon cannot support he number of connections required. If you set connection pooling off this works OK for MySQL because it uses threads (this I don't get MySQL threads are ok but Java ones are not?) but Ohh.. my if one was to every use a database design for large systems such as PostgreSQL you would be creating heavy processes for every connection and again this would not scale. J2EE application servers use connection pooling :) and this is configurable so you can optimize it based on YOUR application not the number client connections.

      PHP caching I have used very little of. I used the PEAR caching system and it works OK. The J2EE caching that I have used is the Jboss implementation. The J2EE caching is so much more finegrained than the PHP caching that it is almost like comparing applies to oranges. But J2EE has a concept of row level caching vs. PHP which has a concept of query level caching. My experience is that J2EE caching is faster and much more intelegent.

      PHP supports objects ... (sorta'). In the projects I have worked on it is really nice to have name space which is something PHP does not support. As the applications get larger I found that keeping track of all the PHP functions became cumbersome. Then I started using PHP objects which at first where great except they are limiting after you have used a more fullfeatures language like Java or Python. I thought I read somewhere that you can do pass by refrence in PHP but I haven't been able to find that link. I found out that the PHP objects where by default pass by value when I ran into out of memory errors. In small sites with small object complexity PHP works fine.

      Generally I have found that large application evolve into supporting things I could have never imaged when I start working on it. If I where a C programmer then PHP might make sence because I could extend it to support all the features. But I don't have the time or knowlegde to become a really good C programmer so I use J2EE (Jboss).

      --
      Pedro For President!
    10. Re:Seems like a silly move... by Pengo · · Score: 4, Informative


      All the slow EJB installs I have seen have the following problems:

      Use of remote classes where local ones would make sense. Use a session bean to aggrigate the results of a few beans and send out the result you need.

      Bad database design or just poor JAVA programming.

      I have studied EJB extensivly , and can usually get near database-query speed if I think hard enough about what I need. I have read that remote objects should only access session beans, and this is a pretty good idea for the most part.. Your calls should be fewer and pull down the data it needs rather than make LOTS and LOTS of calls...

      Anyway, it's a pretty elegent solution and really forces you to think about design. Solutions such as Caucho's Resin CMP makes it even easier to use an EJB solution for object-relational managment and , with resin imparticuarly is easier than using a roll-your-own JDBC based code.

    11. Re:Seems like a silly move... by the+eric+conspiracy · · Score: 4, Informative

      It's slow, it's a memory hog,

      Nonsense. J2EE's threaded model is far more effecient than Apache/PHP's process per connection model because of the memory sharing. In terms of speed, App servers like Resin

      http://www.caucho.com/articles/benchmark.xtp

      do just fine against PHP in terms of speed.

      it doesn't deliver on the write-once-run-anywhere promise of Java because of the vendors' difference

      True a few years ago before Sun started validating app servers. Now not so true. The ServerSide.com runs on a cluster of machines where each machine runs the same code base on a different vendor's app server.

      What I want to know is how come no PHP advocate mentions scalability? How do you pool arbitrary objects, or cache static data in PHP? How do you distribute sessions in PHP????? What happens when you want to cluster that PHP site??

    12. Re:Seems like a silly move... by photon317 · · Score: 4, Funny


      1) I see Java-lovers have knocked me down -2 overrated so it's back down to 3. Way to squelch opposing opinion there.

      2) To ALL the repliers here: I know exactly what I'm talking about. I have coded expertly and will continue to do so in everything from x86 asm to C to C++ to Java to Perl to ..... enough to know. I have written enterprise-class multi-platform java software with 100,000 users and a terabyte database behind it. I've written dos .com program using "copy con" and the numeric keypad, and everything else inbetween. I'm here to tell you, Java is a fucking pig, and you need to realize it. Don't fool yourself with propoganda just because Java is your life and income.

      --
      11*43+456^2
  5. Re:Perl was ruled out WHY??? by inerte · · Score: 5, Informative

    I'm not understanding the reasoning behind choosing php over perl

    You haven't read the article. There's a whole page for "Why not Perl?"

    --
    Buy a Nintendo DS Lite
  6. Dangers of PHP? I think not! by Anonymous Coward · · Score: 5, Informative

    I find it very funny that some people are posting comments suggesting there are security problems with PHP.

    PHP has had a few security problems but they have all been fixed very quickly, just like many other open source projects like FreeBSD and Linux.

    I find it very amusing the Perl programmers are shocked that Yahoo picked PHP instead of Perl. Perl has its uses but it is not designed for the web, PHP is.

    PHP is easy to learn, powerful and c-like which makes it good for rapid development and web based applications.

    I would have been very shocked if they picked Perl of PHP, in my experience PHP is faster, more secure, more feature rich, way easier to compile and maintain, and takes far less code to accomplish the same things as Perl.

    If you look at hotscripts.com you will notice PHP has more entries than Perl, this has only been the case for the last few months and though it is a small indicator it is obvious PHP is gaining popularity and it is well know it is the most installed apache module on the Internet.

    Furthermore if you don't code for PHP don't comment on it, you don't know what you are talking about.

  7. One Yahoo user's perspective by Waab · · Score: 5, Funny

    As long as the change doesn't cause me to lose the lead in my fantasy hockey league, Yahoo can do whatever it pleases.

    And, if I do happen to lose the lead in my fantasy hockey league, I now have something to blame it on.

  8. makes sense... by Anonymous Coward · · Score: 5, Informative

    ...considering it's initial creator is now a Yahoo! employee

  9. Re:hmm... by Anonymous Coward · · Score: 4, Funny
    *applys for a job*
    Be sure to spell check your resume before your applys. ;)
  10. Re:Perl was ruled out WHY??? by ceejayoz · · Score: 5, Informative

    Quoth the link:

    Cons
    - There's More Than One Way To Do It
    - poor sandboxing, easy to screw up server
    - wasn't designed as web scripting language

  11. Re:Dangers of PHP? I think not! by Anonymous Coward · · Score: 5, Insightful

    PHP's biggest security problem is it's users. PHP is a powerful and easy to learn and use tool, which means it attracts a lot of new users. And the more new users you have, the more new user mistakes are made.

    PHP has made a grep step forward in disabling register_globals by default. Unfortunately, a lot of legacy code isn't built for this.

  12. fascinating by erikdotla · · Score: 5, Interesting

    I'm glad Yahoo is moving to OSS and recognizes the dangers of proprietary software.

    I'm a Perl guy, and it was very interesting to note that:

    1. Perl beat PHP in all of their performance tests
    2. They listed TMTOWDI as a "con" yet,
    3. One of the requirements was a language that didn't require a CS degree to use. TMTOWDI helps that, I've noticed.

    I'm saddened that Perl has lost a major cheerleader but at least it isn't MS technology.

    Even so, I can actually see how PHP is more appropriate. For a site with lots of content, with code mixed in, PHP's "code in the page" model is more ideal. I've had to reinvent something similar in Perl many times, appropriate for whatever I'm working on at the time (I don't like Mason, I prefer my own solution.)

    I can see how a solution such as mine - where I prepare an output hash of data then show a webpage by opening and printing the file, using s/// to insert my hash contents with a search/replace method, isn't exactly ideal for Yahoo's high-content needs.

    While PerlScript somewhat solves this problem, I remember it being buggy and certainly not as mature as PHP in that regard.

    I can't say that I think this is a mistake on Yahoo's part - more like, I think if they wanted to, they could solve Perl's shortcomings and reap the benefits that Perl has over PHP. I guess they're just not interested.

    The presentation was a little vague, wish I knew more about the details of their decision.

    --
    # Erik
    1. Re:fascinating by pHDNgell · · Score: 4, Insightful


      3. One of the requirements was a language that didn't require a CS degree to use. TMTOWDI helps that, I've noticed.

      I have to disagree strongly here. TMTOWTDI generally means that two implementations of the same design are different enough that someone without a lot of experience probably wouldn't be able to tell that they were the same thing.

      Having standard ways to do things makes it a lot easier to understand what's going on and makes it a lot eaiser to do things. Even in perl, people try to find a common way to do things, and it often ends up being regular expressions, even where there are far easier solutions.

      --
      -- The world is watching America, and America is watching TV.
  13. Why is PHP so bad? by Anonvmous+Coward · · Score: 5, Insightful

    I skimmed the comments so far and it seems like some people don't have a very high opinion of PHP. It's one thing to feel like something is better, but to despise it baffles me.

    I do programming in PHP and have found it not only to be useful, but quite an upgrade over ASP. Is there something inherently bad about PHP that should make me shy away from it, or is it more of a religious debate?

    1. Re:Why is PHP so bad? by watchful.babbler · · Score: 4, Interesting
      Is there something inherently bad about PHP that should make me shy away from it, or is it more of a religious debate?

      Praise the Lord and pass the pretty-printer! I'm not a PHP fan, but I don't think any of us can make a strong argument against it, except that it's not a general-purpose language, and thus falls into the same geek category as Cold Fusion, Office macros, and, well, ASP. There's a very strong bias against using tools crafted for the job when the job is defined as a presentation method.

      If you like, blame the tacit geek belief that any language they learn should allow inline assembler, have CORBA bindings, multithread, and let you hack a serial port monitor to control intelligent coffeemakers.

      --
      "Freedom is kind of a hobby with me, and I have disposable income that I'll spend to find out how to get people more."
    2. Re:Why is PHP so bad? by asolipsist · · Score: 4, Informative

      PHP is not 'so bad,' but there are reasons why you might not want to use it.
      Here are a list of reasons why PHP may be suboptimal for web publishing.

      1. Lack of seperation between content and logic. Embedded logic code inside presentation can lead to a bewildering jungle of death for anyone who tries to maintain the code. Also, repeated logic must be maintained across all pages, instead of changing it in one place. (this goes for all ASP, PHP, perl type scripts)

      2. Performance problems with interpreted languages

      3. Can't take advantage of OO goodness. php is a flat procedural-like language, you can't do the robust object modeling, or any of the other spiffy OO things you can do with c++, java, (maybe .net) etc.
      4. HTML lock in. Your code will forever live in HTML, if you want a different display format (unlikely) you're stuck. ie. what if you want to have a propriatary client instead of html on your plam, you have to rewrite all the logic.

      5. Fancy features availible in Java (maybe .net) first. Oracle Objects, native DB connectors, will probably be written for Java before anyone tries to implement them (if ever) in PHP. You might not need these features of a small site, so its not that big of a deal.

      Don't get me wrong, i think PHP is great for certain types of applications, but for large sites like yahoo, I think they'd be better off choosing something else (they wont use java because they claim FreeBSD has threading problems)

      These are mostly addressed in the linked Y! eng slides. I'd be interested in hearing others opinion on this topic.

    3. Re:Why is PHP so bad? by Grip3n · · Score: 4, Interesting

      I myself have been an avid user of PHP for many years and I love it, but true, there are many that despise it.

      Why?

      Because like Mr. Radwin says(the author of this presentation), PHP is simple to use. It has quite a bit of error protection and it deals with sloppy code. The elite programmers amoung us hate this - they see people whom have not spent the last 12 years of their life learning a language but producing the same (or similar) results. PHP itself is great, and the fact that a corporation like Yahoo! has decided to use it over all the other alternatives just re-enforces that.

      --
      To make a pun demonstrates the highest understanding of a language
  14. Re:Oh my god! by mr_z_beeblebrox · · Score: 5, Informative

    PHP useful at something!!!

    I didn't expect the spanish inquisition. Really, though. PHP is like PERL made for the web, it has easier access to databases than any other language I know of (which are only a few granted but Perl and C are among them).
    I would say more but Language choice tends to get religious. Everyone thinks theirs is superior and few will just yield to my choices :-)

  15. Why I'm excited about this. by heldlikesound · · Score: 5, Insightful
    Not that I give two rips about Yahoo, but I am glad to see PHP being embraced by companies that are considered "heavyweights" in the industry. It helps dispel the myth that ASP is the "industry standard" and paves the way for PHP / OS databases to be accepted or at least considered when beginning a project.


    It will be nice to go to a large corporate client that is looking for an enterprise solution (what the hell does that even mean) and say something like:
    "I'd reccomend using PHP and Postgres on the backend of the project, given Yahoo's recent success, I think the platform is powerful, sucure, and cost-effective."


    I realize that what Yahoo does in reality is irrelevant, but executives like to hear that kind of shit. Of course that assumes Yahoo can make it all work well, time will tell.

    --


    Cloud City Digital: DVD Production at its cheapest/finest
  16. Re:Oh no! by mr_z_beeblebrox · · Score: 5, Funny

    Would the PHB's like it?

    engineer:this is a rare opportunity phb: hmm?....
    engineer: PHP is not yet a buzz word...we can set the market, indicators would rise, indexes improve, shareholder confidence would surge!
    phb: WOW! I want PHP!
    Jr. Engineer: What did all that stuff you said mean?
    (clever)engineer: With Y having nearly 11M lines of code to rewrite in a new language....it means job security (and we still don't have to wear a suit)

  17. Lack of understand of how PHP works? by Inoshiro · · Score: 5, Informative

    "The drawback of using a code in template system, is that your code and HTML output quickly become forever intertwined."

    You see, the funny part here is that I write PHP, and I do not intermingle my XHTML and PHP at all.

    How does it work? Very simply! Your request handler parses the request, reads in any cookies, sets and changes, reads in the template from disk or cache, fills in the new variables, and pushes it to the client.

    Look, mah, no PHP/XHTML mingling! You move from a "myFirstPHP" model of HTML with PHP shoved in, to a proper model of a complete HTML document produced in anything with %%variables%% strewn throughout which are replaced at runtime by the PHP engine. With this separation of application logic and appearance, you get all the benefits of PHP with all the benefits of a separate interface code level (.NET WebForms does something similar, and Perl can easily do this too).

    --
    --
    Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
  18. Re:PHP is *the* industry standard by puppetman · · Score: 4, Insightful

    The concept of Industry Standard isn't defined by "running on all platforms".

    It means the software has a near monopoly on web development. It's popular, but so are CGIs, Cold Fusion, Flash, VB Script, Java Script, and of course JSPs.

    What irks me is that people haven't abandoned HTML for all but display. HTML was designed to be stateless; info wasn't remembered as the browser jumped from one page to the next. To overcome this, all sorts of gross, kludgy, slow and complicated technology has been created (including JSPs, PHP, etc, etc) to overcome the inherent statelessness of the web.

    The most interesting technology I've seen (and one that I hope will put these lame ducks out of their misery) is Curl, a programming language that runs in a plug-in (yes, sort of like Java, but more advanced, with fewer of the drawbacks). It was started at MIT via a US DARPA-funded project, and includes Timothy Berners-Lee, the creator of the World Wide Web and Director of the W3C, as one of the founders.

    I can't wait for the Internet to go back to what it's good at - serving up pictures of pretty, naked women.

    No, I don't work for CURL, or even for a company that uses the technology. I just think it's a better mousetrap.

  19. Re:Perl was ruled out WHY??? by tzanger · · Score: 5, Insightful

    I agree, I just thought I'd point out that this doesn't change the fact that perl is HELL to maintain for larger projects :)

    Bullshit, or at least bullshit that Perl makes it harder to maintain than any other language.

    Code properly, document correctly and adhere to the same design rules for any other maintainable project (which includes firing the assholes who think that obfuscated perl has a place in a maintainable project) and you will have no more difficulty in maintaining a Perl project than you will any other.

    The fact that perl lets you create a mess may be open to debate, but it certainly doesn't mean it will be a mess.

  20. There are many good reasons. by Anonymous Coward · · Score: 5, Informative

    I work for Yahoo!.

    We chose PHP because our proprietary scripting language didn't give us any performance advantage anymore. PHP is a language with a lot of use and a large group of people in the workforce that know it. We wrote our proprietary solution at the time because nothing else could give us the performance that it could. Things have matured, and with accellerators such as Zend, PHP is a fit for us. There are many more reasons outlined in the presentation. Read it.

    Some people here appear *angry* that we didn't choose [their favorite language] and all I can say to you people is "grow up." PHP is a fit for us. Your solution is a fit for you. Get over it. We know *quite well* how to run enterprise sites, and the decision to go with PHP was not made by the clueless.

    Yes, we use PHP. We use Perl. We use Python. We use TCL. We use C/C++. We use Java. We use Apache. We use FreeBSD. We use Solaris. We use Windows. We use Linux. We use GCC. We use GPL software. We use BSD software. We use proprietary software. We use a lot of things. This isn't really news.

    1. Re:There are many good reasons. by T3kno · · Score: 5, Funny

      Um...just because you have an email address @yahoo.com doesn't mean you work for Yahoo!

      --
      (B) + (D) + (B) + (D) = (K) + (&)
  21. Next Obvious Question... by DarkHelmet · · Score: 5, Funny

    If Yahoo can do it, why can't slashdot?

    --
    /^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
  22. Re:Oh my god! by Anonymous Coward · · Score: 4, Informative

    I hate how uninformed people (I'm not saying you are, but you are certainly propagating the myth) always say something to the effect that PHP is "web only". This is downright false. I've written complex shell scripts with PHP, and tend to do so most of the time over sh or Perl.

    #!/usr/bin/php works just like the Perl alternative.

  23. Alot of this is pure crap by brunes69 · · Score: 4, Informative

    Points #1 and #4 are totally off base. It is very simple to seperate presentation logic from processing logic in PHP. Don't diss the whole language just because 95% of people don't know how to use it properly. you can either go the simple route, and use a special Display class for all your displaying ( easy to modify, easy to swap out for a totally different page), or as I did, you can use PHP's XML/XSLT functionality to totally seperate your logic form display, but having all logic code return XML strings and only at the funal step transform them using XSL.

    As for your point $3, see my exmaple above. PHP has a nice OO clas structue, which is great once you've used it for awhile and being to understand how it is "OO Designed for Web Development", not "OO for Application Development", which are two different things.

  24. Big Whoop. by brunes69 · · Score: 5, Informative

    This doesn't tell me anything about the quality of these products. I cant speak for the others, but have you ever looked at the source for PHPNuke? It is a horrendous mess. Not only that, but the thing is routinely riddled with secuirty holes and other bugs. I had the displeasure of running it on my site for awhile, what a mess.

  25. They passed on Java because FreeBSD is crappy? by doomdog · · Score: 5, Insightful


    According to the slides, the only negative thing they had to say about Java (J2EE / JSP / etc.) is that FreeBSD has really lousy thread support (and proper J2EE solutions require threading)...

    To me, that seems like a really stupid, short-sighted way to approach the problem. If Java is the best solution for them (which I think it would be), then why not move to an operating system that properly supports it?

    Why hamstring yourself to an inferior solution just because you don't want to give up FreeBSD? That's like complaining that your Pinto is too slow -- but you'd rather fill it with Premium gas to get a little performance boost instead of getting a better car.

    And what's up with 4500 servers? What a nightmare! Who in their right mind would want to deploy and manage 4500 servers? If they were really serious about this, they'd upgrade to a couple dozen big-iron IBM mainframes (like one of these!), where it can run hundreds of virtual Linux instances (if needed)...

    I guess it goes back to the old saying "When you only have a hammer, everything looks like a nail"...


  26. Re:Oh my god! by tfoss · · Score: 5, Insightful
    I wonder if they've thought about the performance hit


    Dude, this isn't some little backwater ecommerce site, this is the most hit site in the world. I think it's safe to say they considered the performance. (BTW check slides 30-34 of the link for that exact info)


    -Ted

    --
    -=-=- Quantum physics - the dreams stuff are made of.
  27. Big Mistake by Pinball+Wizard · · Score: 5, Funny

    Clearly, they should have used Cobol.NET.

    --

    No, Thursday's out. How about never - is never good for you?

  28. Very interesting news by AxelTorvalds · · Score: 4, Insightful
    This is interesting news. Very interesting. I'm not a web developer, I'm a bit twiddler. I've been trying to work on that area simply so I can do more, it's fun to learn and as a consultant you need to be able to do that stuff for clients from time to time.

    I've mostly explored JSP, Zope, and PHP. JSP is cool, tons of support, it feels like and acts like it's the enterprise solution. As such, it's a logical choice for a lot of things because if you need a hammer it's nice to have a sledge hammer. The reality, at least as I've seen it, is it's a bitch. It's huge, it's slow, it takes a super computer to really run, I've seen a fair share of sloppy JSP. It's cool, has all the gizmos that java has and it also has all the gizmos that java has. It seems like you need a ton of crap to build a lot of java stuff, even things from Sun like the JMAPI need 3 or 4 30MB downloads before you can build them and get them working, maybe that's just me complaining though. I'm also not sure what kind of vibe I get about Sun and java as a whole technology any more, I'm not saying it's going away or anything like that but it's not the goose that laid the golden egg anymore either. I don't know I'd tie my cart to java if my cart was as big a yahoo! Again, just my opinions, my C++ and assembly (of all things) skills have taken me farther the last couple years and got me jobs when there weren't any, java has just filled out the resume. While I'm knocking one of the most popular platforms out there let me also throw out the java developer base issue. Java was like a dot.com programming language, in no time it instantly had a huge developer base; how quickly do you think they'll run to the next great thing when/if it happens? I've wondered what would happen if sun started charging for the JDK. Or if .Net 2.0 really rocks and mono takes off.

    Zope. What to say about it. It's the bomb. It's also Python which is huge and on the cusp of going really huge, but hasn't yet. It's its own custom thing. It has a ton of cool parts you can drop in to it. It's probably my favorite. It is also a pain in the ass going to zope.org downloading something and trying to get it to work. It's like they have their own little sourceforget.net running in zope space and it makes the number of available parts look bigger than it really is. It's getting better but there is a lot of dead stuff on there. It also won't drop in to Apache that easily, you usually use their custom server and transport layer. It's not so bad but it's nice to be on mainstreet; it's more trustworthy. Other than that, it rocks, it's just a bit tough to sell it to someone who knows some of the buzz. If it were all up to me Zope would be the next big thing but it doesn't look like it's all up to me.

    Then I stumbled on to PHP and it kind of rocked my world when I first started screwing around with it. For simple kinds of web things, like dumping some tables out of a database or something it's kicks the hell out of anything else I've seen. It seems like a few lines of PHP and it's done. No magic web server/container, just the apache server on your redhat box.. Then some of the tools and kits that have been put together with it make it a much more compelling application platform. Zope really appeals to my aesthetic sense of software engineering, I like python, I like the structure and the object nature it just hasn't caught on like the wildfire I think it is. PHP is close to it in terms of pontential and reusable stuff and it's like the second coming of perl. There are still the stock issues, is it fast enough? can it scale? will it last? It seems like those answers are yes. Can it scale better than JSP? I bet for a shop like yahoo! there isn't a comparison; I bet PHP wins unless they triple the amount of RAM that they have or switch off of FreeBSD boxes to S/390s or Sun "Enterprise servers." Also, PHP has such a grass roots following and has really grown up slowly compared to java, I don't see a lot of PHPers really dumping it anytime soon as it is. Now that Yahoo! is involved, PHP may go up to that next level.

  29. PDF version of slides available by bartash · · Score: 4, Informative

    http://public.yahoo.com/~radwin/talks/yahoo-phpcon 2002.pdf

    --
    Read Epic the first RPG novel.
  30. Re:You forgot about Java... by Pengo · · Score: 4, Interesting


    Some of the larger projects I have worked on , where integration is important and a key to the success of the product, JAVA seems to be the best bet.

    Not to say that things couldn't be done in PHP, probably can... but I have had a lot of luck in writing all my business logic and middleware in JAVA and then using JSP or Servlets + Velocity for presentation. The thing is, it's not something that someone can do without a middleware engineer and a implimentation engineer.

    I have been coding java middleware code ware for almost 3 years now, some of it integrates into web based services, some of it ties into legacy workflow systems and even tied into a IBM mainframe, I just can't IMAGINE doing all of that in PHP... I would of been laughed out the door of my company as a matter of fact with a pink slip in my hand.

    The strength of being able to pull in other 3rd party libraries for various tasks that come up, JAVA is first rate.

    I worked for a company that had a pretty complex logistics based system that integrated with a German logistics ocmpany.. was ALL done in PHP.. I couldn't believe it when I saw it to be honest, but to say the least... was VERY dificult to manage the application as it grew to many hundreds of classes and pages. The company ended moving to an EJB/JSP solution on websphere I think, and eventually was able to cut out about 1/2 of their engineers because the API became quite manageable by fewer people.

    You can't call JAVA hype any more than you can call COBOL, FORTRAN c/C++ hype, because the level of profound impact JAVA is having on the industry at the moment is to those levels IMHO.

    NOW.. if the project doesn't really reach beyond basic web applications, yes, even very large companies have such projects.. I see nothing wrong with PHP. It's actually a breath of fresh air when I need to hack something out quick and simple. I use HORDE+IMP for my own personal email and the email server for my wife on my linux box.

  31. Yahoo SHOULD be using Perl, not PHP. by Deven · · Score: 5, Insightful
    The reasons given for "Why Not Perl?" were:
    • There's More Than One Way To Do It - This is a feature, not a flaw! Perl is much more flexible and powerful than PHP. Maintainability comes from coding standards, not language limitations.
    • poor sandboxing, easy to screw up server - Perl can create sandboxes with the Safe module... (And if there's any rough edges, Yahoo's engineers could probably handle it.)
    • wasn't designed as web scripting language - So what?? With mod_perl and HTML::Mason or TT2, Perl fits this niche well, without PHP's predisposition towards mixing code and data.
    These excuses for not using Perl are hardly compelling; they sound like rationalizations. Perl is a more natural fit for Yahoo's needs, especially considering that they already have 3 million lines of Perl code.

    But they plowed ahead with PHP, and what did they learn?
    • very easy to get some pages up quickly - Expected, but Perl would have been nearly as easy, and probably much easier for their existing Perl programmers.
    • But mixed app/presentation problematic - PHP code and HTML forever intertwined - Surprise, surprise! This is exactly why PHP is inappropriate for enterprise applications. PHP encourages such shortsighted design. Beginners like it, but engineers should know better.
    • PHP != Perl - The "implement twice" problem - They knew that they had 3 million lines of Perl in the backend; why didn't they leverage it? This was avoidable.
    • PEAR != CPAN - repository smaller, less mature than CPAN - Again, this was a foreseeable problem.
    • Surprises for people used to coding Perl - It's not just that some semantics differ. Experienced Perl programmers forced to work in PHP have to live with the frustration of having to write ugly convoluted code for things that would be clear and simple in Perl. PHP 4 filled in many gaps, but it just doesn't work as well as Perl does. (I speak from experience here.)
    So let's see. Their problems with PHP basically boil down to the fact that it's not Perl. (Despite the claims of PHP advocates, it's just not an equivalent substitute.) Of course, any experienced Perl programmer familiar with PHP could see these issues coming from miles away. They rejected Perl as an option, claiming that it wouldn't be maintainable, then discovered the amount of discipline required for PHP -- would following good coding standards for Perl really have taken any more discipline?

    Perl was a natural fit for their needs, and the obvious choice. The entire presentation seems to be an exercise in rationalization, attempting to justify a poor strategic decision. They should have used Perl. (Even now, they should probably abandon PHP and use Perl instead, to save themselves from getting further entrenched into this bad decision...)
    --

    Deven

    "Simple things should be simple, and complex things should be possible." - Alan Kay

  32. These aren't really problems. by mgkimsal2 · · Score: 5, Informative

    1) This one is really annoying. Certain pre-defined variables (I'm not sure which, maybe only user-inputted data) are pre-slashed. So if a user inputs the string 'My name is "Jon"', you get it as 'My name is \"Jon\"'. WTF is up with that? That's not what he said! I can't find the reason for this or anything else about it in the documentation (maybe it's there somewhere, but I can't find it).

    It's also pretty annoying when you don't read the manual - and this one is NOT obscure to find. Section 8 - "Variables" (which is what you're dealing with) has a section about 'Variables from outside PHP':
    http://www.php.net/manual/en/language.varia bles.ex ternal.php

    2) Every time a page is loaded, it has to be re-parsed, as well as any included scripts that it uses. This is very inefficient.
    Then design a better language yourself that has nifty things like variable variables (echo $$b[0]->foo;) and is still faster than most other languages. Or just get a host that will use one of the many caching products available (zend, ioncube, etc)

    3) It's a real pain to include scripts that are in different directories which include other scripts, because they will try to open them relative to the location of the original page.

    Seems pretty damn logical to me. Of course, PHP will also look for files in the 'include_path' which is set in the php.ini file, so it's really looking in multiple places. And it wouldn't kill you to just use a predefined constant like DOCUMENT_ROOT and include files relative to that so your scripts would be portable and a bit easier to move around internally if you need to.

    PHP does have problems - nothing you've mentioned here is a 'problem' beyond the level of mere annoyance to a handful of people.

    Slight plug - those who've taken our PHP training course have never complained about the issues you brought up as 'problems'.

    Cheers

    --
    creation science book
  33. Speed by Andy+Dodd · · Score: 5, Informative

    While this may have changed, a few years ago, Postgresql was a non-competitor for one reason and one reason alone: It was slow.

    MySQL had a reputation for being VERY fast. (In fact, this is why it was chosen for /. - It was the fastest choice available at the time.)

    Again, this may have changed, but in the past, MySQL was the speed king if you didn't need all of the other features that Postgres offer.

    So in short, the one users reason is, "I picked a database with less features/reliability because I need speed more than features/reliability."

    --
    retrorocket.o not found, launch anyway?