Slashdot Mirror


PHP5 Coming Soon

Grip3n writes "PHP5 is well under development and a beta is expected out by March 2003 and released summer 2003. One of the more notable improvements which many PHP developers desired is a substantial improvement in PHP's performance. This is due to a new object model PHP5 will be introducing which handles objects by reference rather than by value. Co-creator Zeev Suraski states the new object model is inspired by the book, "Design Patterns"."

53 of 135 comments (clear)

  1. I'm afraid... by pediddle · · Score: 2, Funny

    ...that it'd be hard to "expect" something to be out by March 2002.

  2. Where is it? by phnx90 · · Score: 2, Insightful

    How come there is no mention of this on the PHP Website?

  3. PHP & XUL by Mas3 · · Score: 2, Interesting
    Is there a (larger) web-application which uses XUL generated by php ?
    I Just found small things like single forms.

    Those apps would have the advantage that you can combine a usable & nice looking GUI with a web application (which can be used from everywhere.)
    GUIs designed with HTML are usually quite limited.

    --
    Stefan

    DevCounter - An open, free & independent developer pool
    created to help developers find other developers, help, testers and new project members.

    1. Re:PHP & XUL by XBL · · Score: 2

      See http://books.mozdev.org/chapters/ch12.html for an introduction to using PHP with XUL.

  4. Porting by eddy+the+lip · · Score: 4, Interesting

    This sounds like a very good thing, and will address many of the things I find cumbersome about the language (namespaces!). But while it sounds full of objecty-goodness, does anyone know how backward compatible this will be with PHP4? It sounds like major changes are in the works, and rewriting my code in six months sounds about as much fun as putting pencils in my eyes.

    --

    This is the voice of World Control. I bring you Peace.

  5. PHP5, now with time travel! by sideshow · · Score: 2, Funny
    a beta is expected out by March 2002

    maybe I'll ditch ASP for PHP after all.

    --

    Hollow words will burn and hollow men will burn.

    1. Re:PHP5, now with time travel! by theCat · · Score: 2

      Actually you wi/ould havn/willn-dropped ASP already/soonest, and in fact I right now am holding a copy of your rather excellent review on PHP5-RC3 dated last summer and titled "What you could/id expect from the past/soon PHP5 final release, which will/wasn released yestermorrow."

      That minor eccentric wobble you all just felt in the Earth's axis of rotation is Douglas Adams spinning in his grave. :-)

      --
      =^..^= all your rodent are belong to us
  6. Re:March 2002? by superyooser · · Score: 2, Informative

    That's just another Smashdot snafu. The article clearly says, "PHP version 5, expected to appear in beta form by March, 2003, and released in the summer of 2003..."

  7. *AMP by Cokelee · · Score: 3, Interesting

    From the article: PHP runs seamlessly under Windows, as do MySQL and Apache. WAMP anyone?

    IMO this is what makes *AMP. Consistency between platforms. I use Apache, MySQL, and PHP religiously, and no matter what kind of machine I'm running everything on it is seamless.
    I'm not saying this isn't true with other scripting languages, but being able to code on anything with a few tools no matter where I am is EXCEPTIONALLY nice.
    PHP's use on large web application projects has been uncertain. Yahoo doesn't feel this way. Neither does Earthlink (WebMail)

    But I suppose perception needs to change--you don't have to have a billion dollars [Article, still reading it. . .] in the bank to make a great web language. (*cough* M$ *cough*) Neither do you need a couple thousand to deploy a website with dynamic content.

    1. Re:*AMP by sporty · · Score: 3, Insightful

      I just wish that there was a way to compile PHP into some sorta byte code. 'cause then you'd write your Mysql, XML, expat, imagemagik, and other php modules IN php. THEN it'd be truely portable.

      Problem is, if your php module you wish to compile in isn't written for your system, your are screwed. Besides, using your language to develop your language forces the language to be bulletproof after age.

      I've run into some oddities with php when you push its limits.

      --

      -
      ping -f 255.255.255.255 # if only

    2. Re:*AMP by RevAaron · · Score: 2

      I just wish that there was a way to compile PHP into some sorta byte code. 'cause then you'd write your Mysql, XML, expat, imagemagik, and other php modules IN php. THEN it'd be truely portable.

      What's your logic?

      Having PHP compile to bytecode wouldn't increase the portability of the extension that interface with libraries and apps written in C. If you want an XML parser to work on all platforms you could write it in PHP. A lot of languages that already perform well enough to write libraries in do that rather than doing it in C. Even with PHP compiled to bytecode, it would still have to interface with those C extension dynlib/.so/dll files.

      It might be a bit easier to maintain ports of PHP extensions if PHP had a FFI (foreign function interface) that was workable at runtime rather than requiring a specific C extension to be written for it. Languages with such an FFI (Smalltalk, Lisp and others) often can call into shared libraries on the platform with a lot less trouble and extra code.

      The only real way around this portability problem is to write everything in PHP or a language with similar portability. There's no reason you can't write an XML parser or image manipulator in pure PHP. Bytecode has nothing to do with this though, other than perhaps increasing PHP's speed to something more workable.

      It's easy to push PHP's limits- it was meant to do relatively simple web templating. And sure, it's great at that for some people's use of it.

      --

      Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
    3. Re:*AMP by RevAaron · · Score: 2

      Yes, that'd be another way of doing it, and IMO much better in the long run. However, it'd probably be silly to hope that the OSS community could put such a thing together, for use by PHP or for any language, especially a cross platform one...

      Oh wait! We're talking about Ximian's Mono or Portable dotNEt/dotGNU... ;) Now the PHP just have to port PHP5 to C# (or another .NET language) and we'll be sitting pretty...

      --

      Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
    4. Re:*AMP by RevAaron · · Score: 2

      Well, OSS people have already put 3 or 4 such things together. The silly thing expecting anyone else of seeing the benefit of using them.

      You could use CORBA as is on GNOME, but in the truest tradition which you mention, people don't use it for aynthing but GNOME, where it would make a good way of hookup libraries for entirely non-GNOME uses as well. COM is a lot thinner than CORBA, but hell, better than writing C extensions for the rest of OSS's days.

      --

      Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
  8. They need it *now*.... by hublan · · Score: 2, Funny

    ... because their website just collapsed under the collective weight of /.

    --
    My spoon is too big.
  9. I blame PHP... by Dr.Dubious+DDQ · · Score: 3, Interesting

    I've been blaming PHP for the fact that I haven't gotten around to learning much of Perl or Java - I've been able to do everything I've needed to so far (Nothing TOO complex, obviously) with PHP. I've been "going to start playing with Java to learn it Real Soon Now" for well over a year at this point...

    On the other hand - from the article:
    "PHP5's object model has syntax very similar to the Java programming language, so it will be easy for J2EE programmers to learn it"

    Using PHP as a metaphorical stepping stone to learn Java then?...works for me...

  10. Re:PHP vs Perl by dt23507 · · Score: 3, Insightful

    Well, I have a couple of opinions.

    1. PHP is a little easier to learn than Perl (at least it was for me).

    2. PHP was designed specifically to generate dynamic HTML, whereas Perl seems to be more of a general purpose language.

    Then again, sometimes it depends upon the application. There are some things that may be easier to implement in one language than the other, you may need the features of one that the other lacks, etc...

    Others may, and probably will, disagree :)

  11. Re:PHP vs Perl by RevAaron · · Score: 3, Insightful

    It's mostly a matter of entrenchment. Perl, being a more general purpose language, would likely perform better than PHP in a lot of areas, including web apps. PHP, however, is known as a "web language" simply because that's where it was marketed too and where it's used. People could (a few do) write full GUI apps in PHP, but there's no real advantage to using it in such an area when there are better options available.

    At some point in history, PHP provided a few features which were relatively novel at the time, at least in the Free software arena, which has a tendancy to be a bit behind the rest of the world. [1] At this point though, you can get templating ala ASP in plenty of free and open languages, including perl.

    I could be full of it though- other than having the benefit of entrenchment, does PHP have any features that truly set it apart from perl, python or any of the more mature languages?

    [1] Not in all areas of OSS, of course, but this statement is relatively true for the mainstream of OSS. There are interesting projects and acedemic research things going on that are doing new and interesting things. Like the regular mainstream, most people in the OSS mainstream aren't interested in doing things better so much as doing them as they already know how.

    --

    Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
  12. Re:PHP vs Perl by josephgrossberg · · Score: 3, Insightful

    Why are PHP and Perl paired together so often? (I like both languages; don't get me wrong.)

    After spending some time toying around with both, their syntactic similarities seem superficial, like the fact PHP has that "$" prefix on its variables and that they use the ugly "->" operator for OOP.

    They seem like distant (free, open-source) cousins at best.

    Joe
    http://josephgrossberg.blogspot.com/

  13. Re:Moore. by Alizarin+Erythrosin · · Score: 3, Informative

    Moore's Law has NOTHING to do with this. Moore's Law has to deal with the density of transistors on an integrated circuit.

    The observation that the logic density of silicon integrated circuits has closely followed the curve (bits per square inch) = 2^(t - 1962) where t is time in years; that is, the amount of information storable on a given amount of silicon has roughly doubled every year since the technology was invented. This relation, first uttered in 1964 by semiconductor engineer Gordon Moore (who co-founded Intel four years later) held until the late 1970s, at which point the doubling period slowed to 18 months

    --
    There are only 10 kinds of people in this world... those who understand binary and those who don't
  14. Issues with PHP by pyman · · Score: 3, Insightful
    I have been using PHP for about 4 years, and I quite like the language. I would much rather use PHP than Perl, VBscript or Jscript.

    However there are some things which I think need to be cleaned up.

    The language is a great big mud puddle of libraries and helper functions. It would be nice if libraries could be imported at script run time (They could be sitting in memory waiting to be imported to negate speed issues) instead being available all the time. Ie If you want to use a function you must explicitly import the module containing the function. Why do I need MSSQL, Postges and MySQL connectivity all at the same time?

    And I really hate prefixing all variables with '$'. Maybe they can do something about that...?

    --
    a ^= b; b ^= a; a ^= b;
    1. Re:Issues with PHP by tunah · · Score: 2
      And I really hate prefixing all variables with '$'. Maybe they can do something about that...?

      And maybe C should get rid of the *'s for pointers, they look ugly.

      Seriously, one of PHP's great strengths is the very nice and simple "do what i mean" syntax, which would be much harder without an easy way to distinguish variables.

      Perl is even more flexible with how you write things, but it has @'s and %'s everywhere. I think PHP has a good compromise.

      --
      Free Java games for your phone: Tontie, Sokoban
    2. Re:Issues with PHP by ProfKyne · · Score: 3, Informative

      Um, if you did that then you wouldn't be able to embed your variables in a string, Perl-style.

      • PHP: "My name is $name\n";
      • Java: "My name is " + name + "\n"

      If you think about it, the PHP way is easier.

      --
      "First you gotta do the truffle shuffle."
    3. Re:Issues with PHP by TheLink · · Score: 2

      That's not really a feature that distinguishes Ruby from Perl.

      With Perl you can do something similar:
      print "Result is: ${\( myfunc($somevar)*2 ) } bars";

      It's a tad uglier, but still practical. That's perl for you ;).

      It also works with the <<"HERE"; stuff.

      Stupid that selecting "plain old text" in slash still requires me to use &lt; to represent '<'s

      --
    4. Re:Issues with PHP by TheLink · · Score: 2

      You're welcome - I copied the idea from some site when I was learning Perl + DBI + CGI. Can't find the source at the moment.

      I've actually used it in production stuff.

      Though it is indeed ugly, it's convenient enough when you want to use the output of a few functions right in a multiline string. And you don't feel like creating a few throwaway variables a few lines up, just to stick them in the string.

      Explaining it to some people is a bit less convenient ;). So I'll be happy to learn of other alternatives.

      TMTOWTDI :).

      --
  15. Using design patterns by Wizard+of+OS · · Score: 4, Interesting
    The quote above states:

    Co-creator Zeev Suraski states the new object model is inspired by the book, "Design Patterns".


    While this isn't false, it did get me on the wrong foot. It appeared to me as if the PHP developers were just realizing that stuff like design patterns exist, and started writing their code accordingly. THe article however states:


    "The way PHP4 was built -- it was not easy to implement design patterns," says Suraski. "PHP5 is much more suitable, so you will be able to take that book and implement the design patterns in your code."


    It would've been helpful if that quote had been in the post, but it makes clear that PHP5 will have much better OO features than PHP4 currently has.
    --

    --
    If code was hard to write, it should be hard to read
  16. One person's experience with PHP ... by tdelaney · · Score: 4, Interesting

    ... and why I won't go back.

    PHP 4.2.3. Windows 2000.

    90% of the way into a decent-sized project, I started experiencing somewhat random crashes. Somewhat random in that there seemed to be no consistent way to provoke them, but once they started happening they happened in precisely the same way, consistently.

    Simple changes, such as adding a single character to a script, would "fix" it on a particular machine ... and sometimes expose it on another machine. I'm talking about adding a blank line to a script. It seemed likely that there was a memory error of some kind in PHP.

    Downgrading to earlier versions of PHP 4.x didn't fix the problem. Downgrading to 3.x was not feasible ... transferring to a 3rd-party session system that was incompatible with the 4.x sessions and completely untested by us was not possible by that time.

    Of course, I attempted getting the source code and finding the problem myself. Unfortunately, none of the 4.x versions would compile. The 3.x versions would - but 4.x wouldn't. Obviously, some black magic was required. Sacrifices failed.

    Time was running short. Faced with a very short deadline, I made the only decision I could ... I dumped PHP. I was in a situation where I could not trust the underlying technology.

    As an indication of what dire straits I was in, the technology I eventually recommended to replace PHP and Apache was ... IIS 5.0 and Active Server Pages. Believe me ... if there had been any other viable option, I would have taken it. mod_python looked viable at first, but I didn't have time to go through the cycle of building a single-threaded python, and verifying the underlying technology. With ASP there was a fairly direct translation from PHP.

    I hate that this application has been written in VBScript. The shenanigans I had to go through to get a particular COM control to load and be controlled by IIS - it's system of impersonation doesn't work very well if the COM object isn't specifically designed to be used with it. Under Apache it was able to run as LocalSystem ... which was acceptable since the users are trusted. Under IIS I eventually needed to create an administrator user which a single page uses - all other pages use a Guest user.

    Obviously I was doing something outside the norm, since there are thousands of web sites which use PHP as the underlying technology. I suspect most of them are running 3.x. But the sheer number of issues that I found with PHP during the relatively short development cycle convinced me that it was in no way mature enough for us to trust our work to it.

    1. Re:One person's experience with PHP ... by Twister002 · · Score: 2

      You were probably running it as an ISAPI module instead of in CGI mode. I've had problems on Windows boxes running it as an ISAPI module, it even says the ISAPI version isn't stable in the read me, but I haven't had any problems running it as a CGI.

      Your ASP/COM problems sound weird to me. if you haven't already, look into using MTS/COM+ with that object.

      --
      "For a successful technology, honesty must take precedence over public relations for nature cannot be fooled." -Feynman
    2. Re:One person's experience with PHP ... by Lord+Omlette · · Score: 2

      Sorry, but that's not fair. For some reason, it's as if they completely and totally forgot to do regression testing w/ the goddamned release.

      utime doesn't work. That means
      touch doesn't work.
      gzip doesn't work.
      error messages don't get reported.

      I begged my boss to roll php 4.2.3 off the servers and he did as soon as he saw what I was talking about...

      Other versions of php are just fine, check 'em out!

      --
      [o]_O
    3. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      I was indeed using the CGI module (the ISAPI module looked *way* too flakey for me to consider).

      The COM stuff isn't surprising, as we're doing fairly unusual stuff with something that wasn't really designed for it.

    4. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      Whilst you *can* use JScript, it really isn't as well supported as VBScript. VBScript is the "native" ASP language, and everything else is a second-class citizen.

      One of the reasons for moving to ASP/VBScript was familiarity - much to my dismay, I have written extensive amounts of it :(

      I've also used PerlScript before ... for a single project. I gave up on Perl once I started looking at the so-called "object-oriented" aspects. Python is so much nicer.

    5. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      Unfortunately not. Going back to a completely clean install of 4.2.2 and 4.1.2 for example failed to fix the problem.

      It appears to be a long-standing bug.

    6. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      The site was originally specced to use Zope (which I would have been very happy to use ... been wanting to have a look at the ZPT for some time).

      However, the decision was made by someone (I'm not sure who - it was before I came onto the project) that Zope was too heavy-weight for what we wanted.

      By the time PHP failed, it was too late to go to Zope ... the approaches to web development are just so different between the technologies.

      Basically, ASP was the one technology where I could (almost) guarantee having the site in an equivalent state to the PHP version in the time frame. A purely risk-management decision (including the risk of bugs in IIS, etc).

    7. Re:One person's experience with PHP ... by mgkimsal2 · · Score: 3, Insightful

      Bzzttt - wrong.

      There are not MILLIONS of people running PHP under IIS4 and 5, and it's your responsibility to prove that there are that many. It just doesn't work reliably under IIS in ISAPI mode period, which is what most people would want. Running as CGI is godawful slow, and millions of people are not going to pay $ for Windows specifically to use an extremely slow option for dynamic web stuff.

    8. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      Hmm ... strange that I said I was running PHP under *Apache* ... and using CGI no less (in another post).

      So where did you get the impression that I was running PHP under IIS?

      Ignoring the "millions of people" bit, don't you consider 5% (a figure that is probably way higher than reality) having issues that pop up out of nowhere being way too high?

      The simple fact is, the site was developed in PHP over the course of about 2 months, during which time a number of issues came up, but nothing that couldn't be worked around.

      Until finally a major failure in PHP occurred, at a time when we could not dedicate the time to hunting down and fixing it.

      The rewrite in ASP took 5 days. It would have taken considerably longer if it was being done from scratch, but of course we had worked out the problems with the other technologies involved whilst working with PHP - similarly all the design and structural work was done. The rewrite was essentially a translation (taking into account VBScript's flaws).

      I'm sure PHP is fine for many things - but it proved to be unsuitable for what we were doing, and I am unable to recommend it for another project when there are so many better things out there (and no, I don't in general consider IIS and ASP better).

    9. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      It's not something I can prove (since I couldn't get any of the 4.x versions to build ... bits appeared to be missing from the MSVC projects, and I've never used MSVC).

      However, the symptoms I was getting were extremely indicative ... in particular that a single space or newline (which should be insignificant) could either show or hide the problem. It was most likely a buffer overrun ... but not for sure, since I could provoke it on very short files (buffer overruns tend to be on larger chunks of data), and *adding* stuff to files could hide the problem. Plus it was consistent across reboots (which implies it was in the PHP memory space).

      As I said, not mature enough for use to rely on. We might have had it work on all our dev and test machines, but then fail on the production machine. We couldn't know.

      Whilst we have the same problems with IIS (can't know for sure that it works) we at least haven't had it *fail* anywhere. Cracked yes (Nimda) but not a basic technology failure.

    10. Re:One person's experience with PHP ... by TheLink · · Score: 2
      I've also used PerlScript before ... for a single project. I gave up on Perl once I started looking at the so-called "object-oriented" aspects. Python is so much nicer.


      Aren't Python's object oriented aspects much nicer than PHP's too?

      I can understand using Python over Perl when you want OO, but why PHP over Perl?

      Really curious.
      --
    11. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      Not in the slightest. Please stop trying to suggest that I'm a moron. Chances are I know more about such things than you, but I'm not going to get into a pissing contest with an anonymous coward (or anyone for that matter).

      5 machines - 3 development machines, 2 servers (rack mounts, very high quality control). All exhibited the problem in different ways, but the problem was consistent when it happened.

      If it had been a hardware problem, the results would have been inconsistent (happening not just in PHP, and not in exactly the same way each time on the same machine, across reboots). Whilst I would normally expect more inconsistency with a memory problem, due to differences in the order of things happening, it is actually not surprising that this is consistent. PHP performs exactly the same steps each time it loads up and runs the offending page. As CGI, it has its own memory space, so it *should* hit the problem in the same way each time.

      No problems (other than general windows and specific application ones ;) have been noted with any of those machines since the changeover. One is the machine I've been using every workday for the past two years.

      The most likely explanation is a bug in the PHP 4.x codebase, which has been exposed because I'm doing something unusual. Most people simply do the usual things with PHP ... display pages with data extracted from a database. Since these are the most common things to do, bugs in those code paths have already been found and fixed.

    12. Re:One person's experience with PHP ... by djupedal · · Score: 2

      I'm not buying it...well, I was until the IIS & ASP promo came along.

      t'iz a poor man that blames his tools...

    13. Re:One person's experience with PHP ... by eric2hill · · Score: 2

      I started with a new company in August and the first thing I was tasked to do was build a bunch of dynamic-content web pages for a new web site.

      What was the first thing I did? Scrap IIS and VBScript in favor of Apache2 and PHP. PHP runs WONDERFULLY as an Apache2 module, and I have had literally ZERO problems with this install on Windows 2000.

      Running Apache has been a dream compared to managing IIS. We use Oracle for our back-end database, and PHP's OCI8 module has performed flawlessly. So far this solution has been installed on 3 different web servers, and I have yet to see an "unexplained crash". I get errors in the logs because of bad code in some of the pages or a missing file here or there, but Apache2 just keeps on working and PHP just keeps on serving pages.

      I would guess that you're running into a scalability problem with IIS and spawned processes. Last time I used IIS, it seemed like it wouldn't release process or object handles until the service was restarted. After a while, the system would literally run out of new process handles to give out, and new processes wouldn't start up. Restarting IIS always seemed to cure the problem, but what a PITA. That's when I switched to Apache2+PHP and haven't looked back. I can't suggest the ISAPI plugin since it's listed as "buggy", but it makes me wonder if the plugin is really buggy, or if IIS has issues with external scripting engines...

      --
      LOAD "SIG",8,1
      LOADING...
      READY.
      RUN
    14. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      How many times do I need to state this? The problems were manifested with Apache 2.0.40 and PHP 4.23 (and 4.22 and 4.12) running as a CGI module on Windows 2000 (Pro for development, Server for testing - never got to production).

      If it had been loaded as a long-running process (Apache module or IIS ISAPI module), I doubt I would have seen the consistent error - instead I would have seen much more random errors as different things would happen in different ways. By running as a CGI module, I was ensuring that the exact same sequence of events was occurring each time ... executable was loaded (and memory space assigned), script was read, and somewhere along the line something bad happened.

      What you are doing sounds exactly as I described - you are doing the *normal* things with PHP - primarily serving pages generated using data from a database.

      I *expect* that my case is unusual - otherwise all these PHP sites would be failing left, right and centre.

      However, the fact that I did indeed encounter these problems, plus the general immaturity of much of PHP (for example, the session-handling) means that I cannot recommend the technology.

      Not to mention that it was almost as much of a horror to program in as VBScript :(

    15. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      I hate IIS and ASP. It sucks. I avoided recommending it for as long as I could as I evaluated other alternatives. The fact that I was willing to recommend it told everyone exactly what a shitty situation we were in, as they knew I would only do such a thing if it were the only viable alternative given the time frame and available skillset.

      Does that sound like a promo to you?

      I've posted a lot on this topic - more than I've ever posted on a topic before. Why? Two reasons.

      1. To clarify some misunderstandings about the situation (what technology was used, and when).

      2. Many people seem unwilling to accept that *sometimes* an open-source tool is less suitable for a particular purpose than a proprietory tool.

      I'm not saying that IIS and ASP were *good* tools. But they were more usable for our needs.

      If it had not been for that one single showstopping bug the web site would be using PHP right now, despite the other flaws we found.

    16. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      No real OO involved in the PHP stuff ... except interacting with COM objects.

      In any case, I would have much preferred a Python solution, but most of the decisions were made before I came onto the project. In particular, Zope had been thrown out for being too "heavyweight".

      Unfortunately, the timeframe of fixing it did not give me enough time to set up a mod_python solution.

    17. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      Actually, it was the very first thing that occurred to me. I spent a lot of time investigating the possibility.

      The point is though, that *random* crashes are a Windows trademark - not crashes which appear to be random in how you provoke them, but consistent once they start happening.

    18. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      Nah - there's absolutely no database access involved in this application. As I've stated, we're doing some fairly unusual stuff ;)

    19. Re:One person's experience with PHP ... by pavera · · Score: 2

      ROFLMAO
      being cracked by NIMDA isn't considered a basic technology failure??? WTF
      Thats the funniest thing I've heard ever.

    20. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      Nah - it's more of a design failure :( It can be really hard to close everything down on a Windows machine - by design everything is open (urgh). Nimda used about 6 different attacks on different technologies to propagate ...

      Security is the #1 argument I have against IIS.

      In any case, if *I* had set up those machines, they would have been less vulnerable, since I don't let indexing server be installed ... (one less point of attack).

    21. Re:One person's experience with PHP ... by pavera · · Score: 2

      Right I understand that windows is difficult to secure, and I know its a design failure, but its the design of the technology... hence the technology is poorly designed, and therefore, bad, broken, fallable... Anyway, personally I think nimda is a really nice virus, I watched it once eat up a whole 200 seat win2k network... took about 3 minutes... I'm glad I wasn't the admin cleaning that up... but anyway, I see your point, and I've developed alot of PHP/Apache/MySQL websites, and I've never seen anything like what you described... so YMMV and off we go.

    22. Re:One person's experience with PHP ... by tdelaney · · Score: 2

      Long-living ActiveX controls (on a single page) - as in 10+ minutes for a single page to be generated.

      Initially the control was meant to live across page requests, but there proved to be no way to hold onto the the control reference. In the end, doing everything on a single page proved to be a better design anyway.

      As for the control in question ... it's a Microsoft application that was never meant to be used in this way ...

  17. Re:PHP vs Perl by RevAaron · · Score: 2

    Oh, come off of it. Just because I'm disagreeing with the /. mainstream doesn't mean I'm trolling- my post was (relatively) well-formed and sensical discussing specific points that pertained to the matter at hand. A dissenting opinion, yes, a troll, no. If you don't agree with it, try replying to it with a similar level of intelligence (it's not hard), or is just easier to try to mark it a troll in a poor effort to get the pointage down so no one reads the truth?

    (cranky early work day)

    --

    Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
  18. Good comparitive examples... by supton · · Score: 2, Informative

    ...or why python is better on the backend and the front-end.

    Take namespaces for special-purpose library stuff. Or inline eval (include) of logic code (bad, bad, bad). Good analysis (mine) here, including comparitive code to demonstrate my point.

    Like Java, Python already does assignment by reference, copy is optional. PHP is just figuring this out. PHP's language leaves much to be desired in team programming and code readability. Using 'Design Patterns' is only half the equation. You can do component oriented programming, but some languages are going to be better than others at facilitaing it in a manner that works in reality. PHP5, unfortunately, won't hold a candle to Zope 3, which is really going to compete at the level of J2EE and .NET as well-thought-out enterprise component frameworks.

    PHP lacks object persistence, multiple inheritance, full-featured transaction machinery, a built-in security model, an interactive command-line interpreter, and it is too tied to web-scripting only. And becuase it doesn't have a security model that binds operations to roles/permissions, it can't easily put gateway methods with bound roles (like Zope's proxy roles) between web code and SQL code, leading to increased chance of SQL injection vulnerabilities.

    On the other hand, Zope has object perisistence, transactional RDBMS integration and connection abstraction, templated, componentized SQL methods, a security framework, and Python, which is a much better language (explicit is better than implicit). And if you need to do any sort of content-management, Zope has a mature component-oriented framwork in the CMF, with a killer-app implementation in Plone. It also has XML-RPC, WebDAV, Caching managers, and all sorts of other goodies you won't find out of the box in PHP.

    PHP is fast, and it is easy, but it is by no means scalable. PHP offers a gentle slope learning-curve, and quick easy hacks, but is somewhat like a crack addiction. What PHP as a framework needs to do is not reinvent the wheel in the language department, and use a pre-existing, scalable, enterprise-class OO scripting language, and utilize a templating technology that doesn't promote mixing logic and presentation - but what's the point, since it would look remarkably like Zope?

    1. Re:Good comparitive examples... by mgkimsal2 · · Score: 2

      And for your next trick, you'll compare a language to yet another framework, right? Hrmmm... .NET server has 14,000 class libraries, but PHP doesn't have those. Websphere offers (foo) but PHP doesn't. PHP must suck.

      Pretty much all of what you offered there is available in free or commercial frameworks, and the rest is opinion, not fact (python is 'better' - good argument).

  19. Re:Moore. by tomhudson · · Score: 2

    Oh, come on. Moore's "law" has been applied to all sorts of situations, as it's become a part of the general culture, not just geek chic.

  20. Yahoo? by TheLink · · Score: 2

    Funny thing is from Yahoo's own slides it would have seemed that Perl would have been the best choice (assuming they had equal access to good PHP and Perl coders).

    Referring to:
    http://public.yahoo.com/~radwin/talks/yahoo-p hpcon 2002.htm

    YSP = mod_perl.

    From the slides, YSP beats PHP on performance. Just as manageable (PHP still requires discipline). Lots of existing Perl code doing other stuff. YSP uses more memory - but what's 900MB(YSP) vs 850MB (PHP)at 500 concurrent requests?

    BTW: the page uses javascript where href would do (top 10 web design mistake). Doesn't give me a good impression of cluefulness.

    References:
    http://public.yahoo.com/~radwin/tal ks/yahoo-phpcon 2002_files/slide0041.htm
    http://public.yahoo.com/ ~radwin/talks/yahoo-phpcon 2002_files/slide0002.htm
    http://public.yahoo.com/ ~radwin/talks/yahoo-phpcon 2002_files/slide0003.htm
    http://public.yahoo.com/ ~radwin/talks/yahoo-phpcon 2002_files/slide0004.htm
    http://public.yahoo.com/ ~radwin/talks/yahoo-phpcon 2002_files/slide0005.htm

    So why did they really choose PHP over Perl?
    The given 3 Perl cons, and the "Why PHP slide" are a bit weak IMO.

    --