Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
PHP Programming

Introduction to PHP5 343

Posted by michael from the getting-hacked-with-phpnuke-now-50%-easier dept.
Yet Another OO Fanatic writes "PHP core developer Sterling Hughes has a excellent presentation (mirror) about PHP5 online. So far it seems to be the best coverage of the new features in PHP5; highlights include the new object model, namespaces, interfaces, access control and exceptions. Java by any other name..."
This discussion has been archived. No new comments can be posted.

Introduction to PHP5 More

Introduction to PHP5

Comments Filter:

  • yikes! (Score:2, Troll)

    by Telastyn ( 206146 )
    0 posts, and already slashdotted? the subscribers must've gotten to that one early!

    And what's with the java comment, PHP is pretty much nothing like java. It has different uses, different strengths, and different semmantics. When are they going to properly fix PHP like making it stable? (*gasp*)

    • Re:yikes! (Score:5, Insightful)

      by joab_son_of_zeruiah ( 580903 ) on Friday March 28, 2003 @05:59PM (#5619069)
      And what's with the java comment, PHP is pretty much nothing like java. ...
      I understood the sense of this remark to be more about the PHP's and Java's capabilities to access other software systems, rather than a comment strictly about the language. Check out the PHP reference manual. Sure, the language is the first few chapters. Then check out the other *100* chapters.

      One of the things I find fascinating when I compare the two at a system capability level is that they are equally capable. It's just that PHP is so much more easy to use, whereas Java is so much more orthodox. Easy to use often wins over orthodox.

      In the long run PHP has as much chance to be a Java killer as .NET does. In the great battle for free vs. proprietary software do I really need orthodox?

    • (here's the pdf) [php.net] ... many of the changes made bear a striking resemblance to the Java way of doing things Which is hardly a "flame," as one poster accused the article submitter; Java is (still) one of the cleanest language designs around, and gets a LOT of things right.

  • new mysql (Score:3, Interesting)

    by minus_273 ( 174041 ) <aaaaaNO@SPAMSPAM.yahoo.com> on Friday March 28, 2003 @05:13PM (#5618718) Journal
    just came out too. a decent combination of better features. My only wish: that there was an easier way to do subselects. I knwo almost every one uses the php+mysql+apache combination when doing stuff on linux. I also know that many others like me are really pissd off about the whole subselects thing. I for one have written my own functions to do similar things in php. I knowmany others who have as well. Im sure php developers could produce a standard way of doing it and make it faster.. oh well

    • Re:new mysql (Score:5, Informative)

      by Christopher Cashell ( 2517 ) on Friday March 28, 2003 @05:21PM (#5618803) Homepage Journal
      I don't know that "almost everyone uses php+mysql+apache".

      Personally, I much prefer php/perl+PostgreSQL+Apache. And I know I'm not the only one. Sometimes the most popular application isn't the best application (subject to your individual requirements, of course. . . but I've found PostgreSQL to be generally superior to MySQL for essentially all of my needs).

      Oh, and subselects have been working great for me for years now. ;-)
      • mod_perl, postgres, apache and HTML::Mason rock.

        My company will develop in anything for cash, but it has been my experience that this combination is hands down the best general purpose web development setup. Rock solid, fast, extremely full featured, great rapid development, and generally fun to write.

  • And, if you want it right now... (Score:5, Interesting)

    by oGMo ( 379 ) on Friday March 28, 2003 @05:19PM (#5618774)

    And, if you want it right now, instead of waiting for PHP5, go get Ruby today [ruby-lang.org]. It's got all of this, and many more neat features. I've recently been moving PHP over to Ruby, because PHP wouldn't scale to a large project (taking 4-5 seconds to load and generate a page on a hefty server, the codebase was only about a meg and a half of PHP), and because it was incessantly segfaulting for mysterious reasons. I've had no such problems since.

    And ruby's a lot of fun... you can use it for tiny scripts, sites, or large projects.

    • Specifics? I'm running a large internal PHP project, around 300 PHP files, about 2 megs of PHP code in total, and my page loads are fine, fractions of a second. The biggest bottleneck isn't PHP, but database queries in my project. So I'd like to hear about some specifics on what was causing problems.

      Of course its not fair or valid to say "Well I had these problems 3 years ago so it still applies today"..

      • Re:And, if you want it right now... (Score:5, Interesting)

        by oGMo ( 379 ) on Friday March 28, 2003 @05:55PM (#5619048)

        Specifics are about the same. Little over 300 files total (only a small fraction of the complete system unfortunately), about 1.5 meg of code. This is not just a simple database interface, though. It's a complete persistant object system, widget framework, with object access controls, interface building, and the like. It makes development very fast, and lets me do things that would be very difficult with straight PHP (or anything else).

        Unfortunately, when it came to building pages themselves, generating them from objects recursively was the final straw. The times really shot up, although they had been building for some time as the codesize and functionality increased.

        With the new Ruby version, most of the processing, including building the pages, is moved to a backend server (written in Ruby), with a thin layer of CGI (in Ruby) that calls it. Loading the interpreter, parsing, calling the backend, processing, returning, and output is down to half a second on my old p2-350. And the capabilities are far beyond what the PHP version had (although, this was in part due to the fact it's a newer version, but some things PHP's object model would not have been able to handle, such as the integration of any given object, and adding syntax for class and method metadata).

        • Ah, I see. Yes, I developed a widget framework system using Objects, basically an object for each available XHTML element, attribute management, then more complex objects built off the XHTML Element objects to create complex forms and interfaces. PHP's single greatest bottleneck with speed is Zend 1's object creation. Creating around 100-200 objects dynamically takes 5 - 6 seconds to do.

          So I created a complicated caching system to eliminate this. However, Zend 2, the engine in PHP 5 has a completely redon
    • and because it was incessantly segfaulting for mysterious reasons

      Those reasons are undebugged code. No app just mysteriously segfaults (mystery isn't allowed in computers)... if the code was correct, it wouldn't segfault. Might be something minor... and you might have poured over it a million times, but somewhere you're code was still wrong.

      • Re:And, if you want it right now... (Score:4, Informative)

        by oGMo ( 379 ) on Friday March 28, 2003 @05:43PM (#5618989)
        Those reasons are undebugged code. No app just mysteriously segfaults (mystery isn't allowed in computers)... if the code was correct, it wouldn't segfault. Might be something minor... and you might have poured over it a million times, but somewhere you're code was still wrong.

        You're wrong. No script should cause the interpreter to seg, period. If there's an error condition, it should be reported. A segfault is a bug in the interpreter, no matter how buggy my code is.

        Also, you're doubly-wrong, because statement reordering would sometimes alleviate the problem. Also things like calling get_defined_classes() (or whatever it was called) would segfault on PPC, but not x86. (This was fixed recently.)

        • Ah hem, but you're wrong. Well, a little bit right. No script should segfault the interpreter, but there's no good way I know of to keep the interpreter from segfaulting when the script makes calls to functions that drill down into shared libraries or .dll's. As long as something's in the same process it can take the whole thing down with an invalid memory access. I see it all the time in Java code using JNI to get at Win32 .dll's. It sucks, yes, but it's not the interpreter's fault.

          Now, today I'm run

          • Re:And, if you want it right now... (Score:5, Informative)

            by oGMo ( 379 ) on Friday March 28, 2003 @07:35PM (#5619708)
            Ah hem, but you're wrong. Well, a little bit right. No script should segfault the interpreter, but there's no good way I know of to keep the interpreter from segfaulting when the script makes calls to functions that drill down into shared libraries or .dll's.

            There is an easy way. You catch the signal 11, and send an error to the script saying that something happened in the library that wasn't the interpreter's fault.

            The interpreter should not just crash and return no useful output, like PHP was doing.

            As long as something's in the same process it can take the whole thing down with an invalid memory access. I see it all the time in Java code using JNI to get at Win32 .dll's. It sucks, yes, but it's not the interpreter's fault.

            Maybe in Windows this is the case, but not Unix, where you can catch a segfault and do a longjmp to an error handler. Tidy and easy.

            Now, today I'm running a Java application under a web application server and the server would just die -- with no error message. Nothing, not a single line of output. It just exited, logging nothing to a file nor to screen. -THAT- is horribly unacceptable.

            I completely agree. This is exactly what PHP was doing.

        • You're wrong. No script should cause the interpreter to seg, period. If there's an error condition, it should be reported. A segfault is a bug in the interpreter, no matter how buggy my code is.

          Indeed- I think the person to which you are replying either a) is used to mightily shitty scripting languges or b) is used to C/C++, where segfaults show up unexpectedly all too often.
      • Those reasons are undebugged code.

        I spent about six months on a moderately sized B2B site in PHP. I have seen this behavior. In one case Apache would segfault on shutdown. In another, SSL somehow caused PHP to segfault under certain conditions. Yet another had to do with using a COM object from PHP to perform real time credit card transactions. In the first two cases, PHP wasn't at fault. In the last case, PHP handled a return type poorly; if the symbol that pointed to the object was used in a state

    • Re:And, if you want it right now... (Score:5, Insightful)

      by jasondlee ( 70657 ) on Friday March 28, 2003 @05:39PM (#5618959)
      Doesn't scale? I guess someone had better tell Yahoo [com.com].

      jason
    • Naturally, someone else could tell you to take it to the next level, say goodbye to Ruby, and go with Smalltalk. All of the features (and more) of Ruby in a language that is quite a bit more mature, better acceptance in the world of business, and is generally a lot faster- often due to use of more modern VM technologies than "scripting" languages like Ruby, Perl, or Python generally use. Not to mention web app frameworks that only make you do the neccesary work- far beyond simple templating or anything yo

    • PHP wouldn't scale to a large project (taking 4-5 seconds to load and generate a page on a hefty server, the codebase was only about a meg and a half of PHP)

      I agree with Tilde, antis0c, and jasondlee, who all responded to your post. I think you're trolling, I think you really didn't have the problems you said you did with PHP, and I think that even if you did have those problems, I have an extrememly hard time believing it's PHP's fault. In addition to the other people who responded with large sites ru

    • Scale (Score:5, Interesting)

      by Synn ( 6288 ) on Friday March 28, 2003 @08:37PM (#5620078)
      I'm not too sure what kind of system/traffic your site had, but our company runs web-based apps for over 40 insurance agencies across the US.

      We have one server that hosts 42,000 lines of PHP code and sees around 1300 insurance agents each day who log in, generate term/ltc quotes and download forms.

      Most of the above code drills into a seperate MSSQL database server running Win2k, which actually has become our only bottleneck. That server fails rarely during very high traffic.

      Locally the web server also sports a MySQL database server instance which hosts a little under 5 megs worth of rates for Long Term Care quoting.

      For Term Life quoting I pull in a 50-200k XML datastream from an outside vendor.

      The server hosts 1.7gigs worth of downloadable insurance forms.

      All of this runs on a 1Ghz Pentium 3 with a half gig of ram. A good 300 megs of that ram is currently free.

      In the three years this has been running I've yet to see php cause a crash in apache.

      I'd say it scales pretty damn well.
  • "this [the talk] is hosted on NYPHP's servers... and is running Apache 1.3.27 + PHP5. PHP5 leaks worse than the Titanic..."

    And you linked to it from Slashdot and expected it to survive long enough so that any non-subscriber could click on it?!

  • not really (Score:3, Interesting)

    by g4dget ( 579145 ) on Friday March 28, 2003 @05:19PM (#5618784)
    Java has a static type system (compile-time type declarations). PHP5 presumably still has a purely dynamic type system (but the site isn't responding...).

  • We need good examples (Score:3, Interesting)

    by phorm ( 591458 ) on Friday March 28, 2003 @05:20PM (#5618788) Journal
    Hopefully... PHP5 will either address some of the common mistakes (without becoming brainless) or at least have some good example out there.

    If anyone has noticed... one of the major areas of death/slashdotting of sites apart from bandwidth are php URL's... and/or mySQL queries (often on PHP URL's). I've not yet noticed many Perl-run pages that have been slashdotted so successfully as PHP.

    Now, I'm not sure if that's a faultof PHP itself, or that some of the "easier" features of PHP tend to attract less competent programmers and/or misconfigurations?
    • > Now, I'm not sure if that's a faultof PHP
      > itself, or that some of the "easier" features
      > of PHP tend to attract less competent
      > programmers and/or misconfigurations?

      Arguably, it's most likely because PHP is built into Apache by default, so lots of people running a server out of their dorm room use it. PHP is the most likely scripting environment on small machines because, let's be frank, Tomcat is a huge pain in the ass to set up.

      That said, like C++, PHP is a language which is very easy to

    • Re:We need good examples (Score:5, Informative)

      by mshiltonj ( 220311 ) <mshiltonj@NoSPaM.gmail.com> on Friday March 28, 2003 @06:27PM (#5619256) Homepage Journal
      If anyone has noticed... one of the major areas of death/slashdotting of sites apart from bandwidth are php URL's... and/or mySQL queries (often on PHP URL's). I've not yet noticed many Perl-run pages that have been slashdotted so successfully as PHP.

      PHP will run in just about any hosted environment. It is nearly ubiquitous in any shared hosting package.

      Machines used in virtual hosting packages (in the < $50 price range) usually have the web server and the db on one machine with less than a GB of memory, and have upwards of a couple dozen or more sites running on the same machine.

      For many, if not most, sites, especially the non-commercial sites, this is more than necessary. They can be incredibly complex and completely dynamic sites. Such is the power of PHP, it puts great power into meager hands.

      In meager hands, however, one quickly runs out of resources.

      Perl, on the other hand, and more specifically mod_perl, isn't usually in these virtual hosting packages. Why? Because mod_perl really gets into the the guts of apache, and anything really neat requires non-trivial modifications to the httpd.conf file. (not just an .htaccess file)

      Sites that use mod_perl, then, usually have thier own dedicated machines, and in those cases will usually have _multiple_ machines dedicated to serving a site.

      For instance, Slashdot is run using 10 different machines [slashdot.org].

      You'll have to stress test PHP vs. mod_perl on like hardware before drawing any conclusions
      about slashdot-resistance.
    • Now, I'm not sure if that's a faultof PHP itself, or that some of the "easier" features of PHP tend to attract less competent programmers and/or misconfigurations?

      I think that's one of the big problems. People are moving to PHP in droves because its so "easy" and so "fast", which is really just marketing hype. It is easier to do small simple things, the "function_name_for_everything" model it follows is easy for HTML people to understand and get the hang of but try doing a large application and then try

    • Re:We need good examples (Score:5, Interesting)

      by Arethan ( 223197 ) on Friday March 28, 2003 @06:40PM (#5619354) Journal
      Slashdotting occurs mainly because 1 of 2 things happens. Either a) the pipe to the webserver is too small and the traffic overwhelms their connection; or b) the hardware falls behind in servicing the requests, and thus pages start failing.

      Usually, it's b). Particularly, database queries being the main culprit. When people write database backended websites, they take 1 of two approaches. Make calls to the database every time a page is requested (most used), or they call the database for the first request, caching the result, and feed the cached copy to all other requests that occur within the cache's lifetime.

      Method 1 is easier to do, but is flawed, in that you are placing all of the load on the database server. Once the requests start to pile up, it immediately becomes a bottleneck.

      There was a nice write up about how some group put together a slashdot proof system, consisting of only modest Sun hardware. Their key was the use of java to run the website. Java allowed them to create system-wide objects that could be referenced by unrelated page requests. So they took method 2 in website design, and had a system that only made calls to the database when the cache didn't already hold a requested page.

      PHP4 (and 3), unfortunately, do not allow for persistant system-wide objects. Not even lowly variables. So you can pretty much bet that any stock webserver using PHP will not handle a slashdot link on it's own. It would need a caching server to keep the requests to the database at a minimum. Hopefully, PHP5 will fix this little problem, as even ASP allows for system-wide objects.

      So the short answer to your last question is: It is the fault of the programmer for choosing the wrong model, but PHP doesn't give them any other option, making their only alternative to use a different language.

      Hope that helps. :)
      • PHP4 (and 3), unfortunately, do not allow for persistant system-wide objects.

        And this is the major shortcoming of PHP for framework based systems.

        I wrote an app which used National Language Support (NLS), used constants for all the "magic numbers", dynamically generated a nested DHTML menu, and so on. When page load times started approaching .8 seconds, I segmented the NLS calls, put switch/case statements around the constant definitions, the SQL file includes, and got the page load times down to .6 seco
      • PHP has had pretty good Shared Memory support for quite a while. Shared memory is plenty fine in this case since most sites only have a few megs of commonly used data.

        Shared memory is a perfectly valid fix for this issue -- but you usually cannot use it on shared hosting packages -- but you cannot do the Java thing either in most cases...
      • System-wide objects are VERY easy to implement in PHP currently. Just use shared memory and sems....

        For more information please see: http://www.php.net/manual/en/ref.sem.php

        "This module provides wrappers for the System V IPC family of functions. It includes semaphores, shared memory and inter-process messaging (IPC).

        Semaphores may be used to provide exclusive access to resources on the current machine, or to limit the number of processes that may simultaneously use a resource.

        This module provides also

        • Re:System-wide objects (Score:3, Informative)

          by Arethan ( 223197 )
          Unfortunately, there are issues with using shared memory that would be better off handled by PHP itself. The integer keys need to be unique, which can be a bit of a pain to generate in the first place, but also lead to issues if other software isn't written correctly and simply uses a hardcoded value. Next thing to you, your data is being screwed with by an unknown app.

          You'd probably be better off using a file based system that stores data in /tmp/phppersistant or something, and uses file locking to contro
    • I've not yet noticed many Perl-run pages that have been slashdotted so successfully as PHP.

      Due in large part to the fact that PHP is used a whole lot more than Perl for web sites. I doubt the language has all that much to do with it.

      Most performance problems in dynamic (Java/PHP/Perl) websites that I've seen are because the database isn't indexed properly.
  • I'm actually OFFENDED that you would compare PHP5 to Java. I don't want to start rambling off the difference (though I will mention EJB and taglibs, just to put something in the hat).
    I'd rather ask the submitter if he'd like to truely argue why he thinks this new version of PHP is just like java.

  • Java? Hardly. (Score:4, Interesting)

    by Graelin ( 309958 ) on Friday March 28, 2003 @05:23PM (#5618818)
    Java by any other name...

    Leave it to a Perl guy to compare PHP to Java.

    features in PHP5; highlights include the new object model, namespaces, interfaces, access control and exceptions.

    Of course, Perl has had all this for some time.

    Just curious, how can you have an object model without namespaces? Or interfaces for that matter? Isn't that like "New Car - with tires!"??

    Either way, PHP makes for a good interface language for web apps - I guess. You can throw it on top of an application layer to do the real work. Last I checked, you could only use SOAP to do this - has anyone tested how well that performs? SOAP doesn't scale all that well.

    It would be nice to let the HTML monkeys handle some of this stuff while the serious development can take place in a real language. /me dawns the flamesuit.
    • Wait. You don't have to pay extra for tires? =)

      I'm still trying to figure out why I had to pay extra for floor mats.

    • Re:Java? Hardly. (Score:2, Insightful)

      by stonecypher ( 118140 )
      > Leave it to a Perl guy to compare PHP to Java.

      Leave it to a Java guy to make asinine comments about practitioners of another langauge. Leave it to a C++ programmer (me) to compound the error.

      > Of course, Perl has had all this for some time.

      Yah, so have lots of languages. That makes it entering PHP no less exciting.

      > Either way, PHP makes for a good interface
      > language for web apps - I guess. You can throw
      > it on top of an application layer to do the
      > real work.

      My, how casually dis
      • My, how casually dismissive. PHP scales far better than Perl does. Go talk to the yahoos at Yahoo!

        I personally don't care what the yahoos at Yahoo! think until they show me some benchmarks.

        More accuratly their programming staff probably complained that "Perl is too hard" (I hear it from PHP developers all the time). Besides if I understand correctly Yahoo was using CGI (which may have been perl but could have been C or something else)

        Scalability depends on a lot more than just the language, it (obviousl

    • Re:Java? Hardly. (Score:3, Informative)

      by RevAaron ( 125240 )
      Just curious, how can you have an object model without namespaces? Or interfaces for that matter? Isn't that like "New Car - with tires!"??

      Plenty of OO languages do not have namespaces. It isn't vital to an object system in the least. They are handy, but far from neccesary.

      Last I checked, you could only use SOAP to do this - has anyone tested how well that performs?

      Last you checked, you could only do what with SOAP? RPC calls? from PHP to anything else? There are plenty of ways to do something
  • Does anyone know if this version will have better support for suexec-style permissions handling without using php as a perl module script thing? If I'm unclear, what I mean is will php commands like chown and chmod actually be functional on files not owned by the user apache runs as, based on the user who owns the site/scripts?

  • Not doing much to improve my opinion... (/.'ed) (Score:4, Funny)

    by tweakt ( 325224 ) on Friday March 28, 2003 @05:34PM (#5618915) Homepage

    The connection was refused when attempting to contact ny1.php.net

    I tried to RTFA, and all I got was this lousy error message.

  • Nice and stable (Score:5, Interesting)

    by Bob Bobbinson ( 574371 ) on Friday March 28, 2003 @05:38PM (#5618945)
    From the blog :

    PHP5 isn't ready

    This is what I get for running a server on pre-alpha software.

    Ok, so as many of you already know, I have my talk for NYPHP online. This talk is hosted on NYPHP's servers, and is running Apache 1.3.27 + PHP5.

    PHP5 leaks worse than the titantic. With MaxRequestsPerChild at 100, apache children grew to 37MB (before we stopped counting). At MaxRequestsPerChild at 40, it was around 27mb. Finally, we've settled on a reasonable default 25 requests per child. MaxClients at 50.

    This is a box that can easily handle 20 times this load. ugh.

    PHP5 is pre-alpha. Don't think otherwise.

  • WORKING LINK (for now) (Score:4, Informative)

    by Thoguth ( 203384 ) on Friday March 28, 2003 @05:43PM (#5618990) Homepage
    http://talks.php.net/show/php5intro [php.net]

    Not trying to karma-whore, I just thought I'd use my +1 for something good because nobody seemed to notice the AC link.
  • Did Slashdot just attempt an upgrade to PHP 5?

  • PHP5 wishlist (Score:3, Interesting)

    by Kunta Kinte ( 323399 ) on Friday March 28, 2003 @05:54PM (#5619040) Journal

    1 - Better variable scoping features. I'd like to be able to say something like...

    session
    {
    $SessionVar1 = 1;
    $SessionVar2 = y;
    }
    where 'session' is a keyword that executes a block of code or variable declarations in session scope, and have those variables persist throughout the session. Same for application scope, that is variables in that scope persist for the entire life of the PHP engine, and available in all scripts. ( was that the ACLs they were refering to? in the story summary? )

    2 - Built in Opcode caching [turcksoft.com].

    3 - More consistant library function naming.

    4 - Support for 'taglibs'. The same functionality can be done using functions, well sort of. But this is very usefull when separating the work between web programmers and non-technical designers/maintainers.

    That's my list...

    But yeah, you're right, I should shut-up and code them or stop complaining.

    • System-wide objects are VERY easy to implement in PHP currently. Just use shared memory and sems....

      For more information please see: http://www.php.net/manual/en/ref.sem.php [php.net]

      "This module provides wrappers for the System V IPC family of functions. It includes semaphores, shared memory and inter-process messaging (IPC).

      Semaphores may be used to provide exclusive access to resources on the current machine, or to limit the number of processes that may simultaneously use a resource.

      This module provides als

  • PHP Is *not* an application server (Score:5, Informative)

    by tweakt ( 325224 ) on Friday March 28, 2003 @05:55PM (#5619043) Homepage
    In PHP, all you have are scripts. Sure they may be optimized, compiled, pseudo-object-oriented and even obfuscated... but they are still scripts. They may even include eachother. But they are still *SCRIPTS*.

    After executing, they forget all knowledge. There is no persistence, no threading, no transactional support. All attempts to improve efficiency are afterthoughts and hacks.

    At one point I tried to implement in-memory "application" wide shared data. The concept is, something may need to be loaded when the site is first loaded, and then it should be kept in RAM, and we need exactly ONE instance of it.

    I gave up... using shared memory was too tricky and isn't even platform independent. It's not part of the core language, and even if it worked, it would not turn PHP into an application. It still runs in a modular fashion.

    Now with a Java servlet, you have an application that is running. Within your servlet you may define some data exist indepently of web requests. Servicing a request is just one aspect of it. Its much more like a real program, which is why it're referred to as an Application Server.

    For very simple things, that don't need to scale, both in usage, and codebase, then PHP is ok. But for design real web applications, which need to be managed by more than a few developers, integrate with legacy systems, implement a full three tier architecure, etc, PHP just doesn't cut it.

    A lot of the bad sites which go down easily when /.'d are simply bad coding. Making 16 database accesses per page is not bad when just a few people visit at once, but when the stampede comes, your toast. Most people don't develop with that in mind.

    Java has some serious strengths in the Web department, it's proven technology, and is not very complicated at all. It's just that most people aren't used to writing structured code. JAva forces you to follow somewhat good practices and the extra work pays off in maintainability. PHP and Perl you can just hack away, without any strong typing, etc and get something done very quickly but in the end it will become a mess quite fast.

    I'm not saying Java will solve your problems, but there is a strong base of best practices, design patterns and example code to help you keep your code in nice shape.

    With PHP, it seems like everyone has their own code libraries, utility scripts, ways of coding, etc and its really tough to resuse someone elses code. Java Interfaces and Inheritence comes in very handy.

    Ok... enough ranting. Anyway, I used to be a hardcore PHP supported because you could whip together things very easy, but as I learned more java and needed to do larger projects and learned more about efficient coding, I realized with PHP you will eventually just run into a wall and that's when it's time to look for better solutions.
    • Well, you outlined the exact reasons I'm moving my code from PHP to Java.

    • You're absolutely right. PHP's not an application server.

      The problem is that's what many, many, people need when they decide to use PHP. That's not PHP's fault, but I believe it's such a big problem that maybe steps should be taken to address this. Either via application server features in PHP engine for through education.

      Maybe in the future this would prevent people from writting CMS applications in PHP.

    • Re:PHP Is *not* an application server (Score:4, Interesting)

      by bahwi ( 43111 ) on Friday March 28, 2003 @06:39PM (#5619352)
      Best reason not to move to Java: click [yahoo.com].

      Programmers determine coding practices, structure, etc. You can find obfuscated java code, obfuscated python, obfuscated perl, or obfuscated php. It all depends on the _programmer_, not the programming language. It's like blaming car accidents on the type of car a person drives.

      Structured code is a good thing though, and so is efficiency.

      Most PHP Projects are put on a shared server, so using shared memory will generally anger the host. For enterprise level, maybe for a simple simple form I'd go with PHP, everything else I would go with something more hardcore, and yes, even Java. Java is a good language, but it's bad to be trapped to a single company for your language.

      Mod_Perl on Apache does shared memory, along with several other improvements. With strict coding practices in a company, and someone going over the code(should be done with _every_ language and _every_ project) the code is easy to read, easy to re-use, and easy to modify. Yes, even Perl. High level enough to do things quickly and easily, and powerful enough to do it very quickly, using shared memory, etc.. Don't underestimate the power of mod_perl, it's easy to get a dynamic database page with mod_perl to load faster than static content.

      And with mod_perl, and good practices(again, necessary even in Java) it will scale easily to multiple servers, legacy systems, etc...

      Of course, we're waiting on Parrot [parrotcode.org]. Yeah, kinda Perl 6, but yeah, it will compile Java. And yeah, cross platform, unlike Java (Java on BSD is a PITA, _and_ reminds me of Win 3.1 on my 33mhz system back in the day).

      So again, the problem is the programmer, not the language. Although you are correct that PHP is not an application server. But look at Parrot and look at Perl, things can grow into even better things.

      Parrot also has a BF (Brain****) interpreter.
      • Best reason not to move to Java.... Java is a good language, but it's bad to be trapped to a single company for your language.

        The same could be said for Visual Basic, .Net, etc.

        You don't really think that IBM would let Java die if Sun ran into real financial trouble, do you?

        The fact is that there are so many large organizations tied to Java the likelihood of it dying out is the same as Cobol i.e. zero.

      • It's like blaming car accidents on the type of car a person drives.

        Sounds fair. You get the Pinto.
      • If Sun dies, Java will still live on. Unlike the completely closed up languages like Visual Basic, Java has a specification that has been used by other companies to create compilers and virtual machines. It is not dependent on any particular company for its ongoing survival, just as C++ and COBOL are not dependent on any company.
    • but if you have a database you could employ a technique for clustering sessions via a database no? so as usual 'best practices' depends on knowing what you are doing...

      UPDATE application_variables SET value='bulshit' WHERE id=1

    • Re:PHP Is *not* an application server (Score:5, Insightful)

      by Dalroth ( 85450 ) on Friday March 28, 2003 @08:01PM (#5619908) Homepage Journal
      I was going to provide a quick and simple response. Then I decided to not get involved. Then I reread your post and couldn't help myself.

      I'm going start out by getting to the point: Java is not the answer to everything. Not everything should be judged using Java as the standard. And finally, PHP is good enough for yahoo? Seems so: http://news.com.com/2100-1023-963937.html?tag=lh

      In the interest of full disclosure: I am a full time senior level architect/programmer for one of the largest mortgage companies in the country. Most of the work I do is C# with an XML+XSL frontend these days. I won't touch any Microsoft product for my own personal projects, so in my spare time I do a lot of C++, Ruby, Perl and PHP work. I've long since given up dealing with Java, although there are Java projects (such as Struts, Cocoon, and JBoss) that I deeply respect.

      I don't even like PHP, but it gets the job done. It gets it done far quicker and far easier than Java and most other languages, and I've long since learned that worse is often better (ask the Lisp community if you don't know what that phrase means).

      To start, I want to point a major flaw in your arguments: Most of these PHP sites are written by amateurs plain and simple. Even a lot of the bigger PHP projects on freshmeat are clearly created by people who do not have a wealth of knowlege, but in it's place have a lot of dedication. That's fine. In fact, that's the way it should be.

      The web was built via the back breaking work of millions of amateurs around the world. These people have just as much right to participate in this medium as us professionals do. Without them the web would be a desolate wasteland of holier than thou illuminati. Instead it's a rich and beautiful medium of communication supported by everybody.

      "I gave up... using shared memory was too tricky and isn't even platform independent. It's not part of the core language, and even if it worked, it would not turn PHP into an application. It still runs in a modular fashion."

      Why aren't you using the session? PHP has supported sessions for sometime now. There's no reason for you to be touching shared memory in a language like PHP. Would you do the same in a JSP page? I think not... Maybe you have your reasons, and PHP session handling is certainly not perfect in all situations, but your lack of an explanation as to what you are doing leads me to believe you either did not explore all possibilities, or you are making judgements based on older versions of PHP that are simply not valid anymore.

      For very simple things, that don't need to scale, both in usage, and codebase, then PHP is ok. But for design real web applications, which need to be managed by more than a few developers, integrate with legacy systems, implement a full three tier architecure, etc, PHP just doesn't cut it.

      Please excuse my english: 3-tier architectures are overrated overrused bullshit. Everybody has a different meaning for them, everybody has a different use for them. The only successfull n-tier architectures I have seen (and this comes from years of distributed COM+ development experience) are those that follow this structure:

      Client -> Provider -> Scarce Resource

      Where client is typically the web browser, the Provider is typically your web server, and the Scarce Resource is typically your database.

      Breaking that into more tiers is imho absolutely foolish. The extra code complexity introduced, the marshalling overhead, latency overhead, thread synchronization issues, deployment issues, and security considerations are simply NOT WORTH IT! Why? Because the ONLY thing that really matters in the long run are your scarce resources!! That's your database! If you minimize calls to your scarce resources, you will get MUCH better bang for your buck than through any other medium. You can always throw some smart caching in there somewhere, but caching is NOT the same as adding an extra

    • Re:PHP Is *not* an application server (Score:5, Interesting)

      by Synn ( 6288 ) on Friday March 28, 2003 @08:17PM (#5619979)
      The "a scripting isn't a REAL programming language" arguement is as tired as it is old.

      I started with Java back when the only IDE out was Symantec's Cafe(not Visual Cafe) and frankly over the years I've found myself to be most productive using scripting languages like perl and php.

      They get things done faster with less code needed to be written in a world where fewer lines of code typically translates into fewer bugs and more productivity per programmer. And I can code in any amount of structure into a project as I see fit.

      Now if I worked in a huge corporation where any idiot could submit code into my project, then yes a language that forces your hand could very well be a good thing.

      But in skilled hands things like strong typing and forced OO really only get in the way.

  • PHP (Score:2, Funny)

    by www!!!1 ( 662326 )
    PHP? What's that? If you can't write it in pure assembly, its not worth writing!
    • To that I say:
      0100100101100110001000000110100101110100011 0 000001 11001100100000011011100110111101110100001000000110 10010110111000100000011011010110000101100011011010 00011010010110111001100101001000000110001101101111 01100100011001010010110000100000011010010111010001 10000001110011001000000110111001101111011101000010 00000111000001110010011011110110011101110010011000 01011011010110110101101001011011100110011100101110 001000000101100101100101011000010110100000101110
  • Great... now I have to upgrade all my servers... Weeee! Oh well, maybe the have some new session stuff.
  • With the never versions of PHP, mainly since 4.0 / 4.3 and now 5, I notice that all emphasis seems to be on improving OO programming. However, will PHP change into a language solely fit for OO programming? Or will good old P/R still be an option in the future? Personally, one of the great aspects of PHP are its simplicity for performing simple tasks. I think this is also one of the main reason that people with little programming experience embrace PHP. To me, total focus on OO programming while loosing th
  • What I would really love to see is a unified database API. It's horrible to have different APIs for each database.

    I know php has odbc support, but ... have you ever tried to make run odbc with mysql in a 100% unix enviroment ?

    Java has JDBC, perl has DBI, Microsoft has ODBC... I am waiting PHP can get something like that !

  • What I can get to anyway through the slashdotting.

    I managed to get to the namespace page, which I feel is one of the biggest problems, and it says nothing about namespace issues other than 'fixing the object model' and changing OP codes so you can add your own (what do OP codes have to do with it?).

    And what does fixing the object model mean? Are they going to create a standard set of classes and move the core functions into them (one can only hope) or are they going to stick with the every_function_in_my_

  • PHP, Java and Problems with new gimmicks (Score:3, Interesting)

    by theolein ( 316044 ) on Friday March 28, 2003 @09:31PM (#5620362) Journal
    While I must admire the PHP developers for going totally overboard and finally adding features to the almost useless class system they had before, I have found that PHP's great strength has been in smaller websites that need simple code. Java has always been overkill in that arena.

    But what has become an increasingly presistant problem is the way that things that are commonly used such as the easy method of automatic variable creation with reg_globals = on, was changed to be default off and similar things that change in every .x rellease. The problem with that is that you don't know anymore if your code will "just work" on an unknown server, or if you're going to have to change php.ini and /or your code (if you do it the new way and the server is old it won't work and if you do the old way and the server is new...).

    This, in my opinion is starting to defeat the object of what made PHP so popular in the first place: making a small script easily in an easy language for a small site.

Slashdot Top Deals

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Close