Introduction to PHP5

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..."

Comments

yikes!

[Telastyn]

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!

[joab_son_of_zeruiah]

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?

Re:yikes!

[kipsate]

In the long run PHP has as much chance to be a Java killer as .NET does.

I don't think so. As one of the first posters with +5 comment score points out, you will run into the wall when doing big projects with a scripting language. And despite all the nice OO-like features that have been thrown in to PHP, it still is essentially a script language.

I have been working on a project where we built a not-too-complex site using Cold Fusion. It started out simple: read in form fields, throw them in the database, read them and present them as a web-page. Cold Fusion or PHP are great for this.

Not much later, the application became more complex. We got more tables, and backoffice people needed to be able to do fairly complex mutations. We ran into the wall with CF. We hired professionals that spent about EUR 500,000 to try to write our back-office system in CF. They never delivered anything (also due to the fact that they were not the most professional company - if they were, they wouldn't have started off using CF).

Now why is it that scripting languages blow up when projects get bigger? You'd say that all you do is showing forms and pumping around data in the database.

We moved over to dotNet (there goes my Karma). Suddenly things became a lot easier. Why? Because we were able to program object oriented, for one thing. (So - java would have been similar order of magnitude improvement over scripting. You may mod me up now. :-)

We were now able to cleanly seperate our code in distinct building blocks, without any overlap. Each class (an OO-building block) had a very clear job. Changes on a class that for instance handled sessions, did not cause other parts of the code needing adaptions. There were just a few isolated classes doing database transactions. Logging, error trapping and user tracking were much easier - we didn't need to pollute many files in our code with LOG messages - we could centralize them using exceptions.

Now some of you may say: "PHP also has this". But PHP is not a pure OO language.

To all who are not convinced that OO-programming is adding any benefit: Get a copy of Bertrand Meyers hallmark book Object Oriented Software Construction right now. It will explain what OO really is about and explains quite scientifically why procedural programming is inferior when programming larger projects that do not need to squeeze the most out of every clockcycle (for instance, backoffice projects, web sites). The book is over 1300 pages, but you can be sure that you will not want to program non-OO anymore before you have even reached page 100. Then it will also become clear PHP is lacking many OO features.

In short, there are many criteria before a language can call itself fully OO (the book mentions 15!). The main benefits OO brings you are reusability of code, and being forced to use a certain structure in your code. PHP does not qualify as OO, despite the OO-like features that were thrown in.

To finish the story: our CF scripts were quickly replaced by C# (the .net language of choice - a somewhat improved java).

There is one other consideration though, that I must mention. Not unimportant: economic considerations. OO-programmers are more expensive and harder to find than procedural programmers. This may lead companies to decide to go for non-OO techniques. But they shoot themselves in the foot as soon as they want to build even a moderately complex back-office.

You can also turn this around: learn OO, be more productive, and have a higher salary as a bonus.

Re:yikes!

[iamdrscience]

Now why is it that scripting languages blow up when projects get bigger?

It's not like this is a feature inherant to scripting languages, Python has very good OO implementation and capabilities and would very easily expand for larger projects. The same is not true of PHP or Perl with their somewhat half-hearted attempts at OO.

Don't get me wrong though you PHP and Perl fans, both of those languages are still great at a lot of things and I'm not trying to slam PHP or Perl. I love PHP, it's a very very fun and useful language, I use it a lot, but there are some things it can't do and some things that Perl can't do that Python, Java and other languages can.

Re:yikes!

[JamesOfTheDesert]

As one of the first posters with +5 comment score points out, you will run into the wall when doing big projects with a scripting language. And despite all the nice OO-like features that have been thrown in to PHP, it still is essentially a script language.

I didn't see any previous comment explaining how using a scripting lanaguage causes one to "run into the wall when doing big projects."

This is an old wive's tale, that scripting langauges just don't scale. It's nonsense; while some languages (perhaps PHP) are not well-designed for large projects, others, such as Ruby, do quite nicely.

Ruby has a a far better OO model than PHP (or Java, for that matter); that one can label it as a scripting lanagauge does not diminish its beauty or power. Give it a shot before dismissing whole categories of tools. Check out these articles

.

Re:yikes!

[Requiem]

In the long run

"In the long run, we're all dead"

- John Maynard Keynes

new mysql

[minus_273]

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

[Christopher Cashell]

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. ;-)

And, if you want it right now...

[oGMo]

And, if you want it right now, instead of waiting for PHP5, go get Ruby today. 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.

Re:And, if you want it right now...

[jasondlee]

Doesn't scale? I guess someone had better tell Yahoo.

jason

Re:And, if you want it right now...

[oGMo]

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.)

Re:And, if you want it right now...

[oGMo]

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).

Re:And, if you want it right now...

[sporty]

You don't know how yahoo uses php. It might use it on command line for generating static pages. So beware what you think they are doing. You never know.

Re:And, if you want it right now...

[oGMo]

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.

not really

[g4dget]

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

[phorm]

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?

Re:We need good examples

[stonecypher]

> 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 put hidden ineffiencies into. So that may compliment the problem.

Re:We need good examples

[mshiltonj]

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.

You'll have to stress test PHP vs. mod_perl on like hardware before drawing any conclusions
about slashdot-resistance.

Re:We need good examples

[Arethan]

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. :)

Java? Hardly.

[Graelin]

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.

Suexec-like support?

[MasterSLATE]

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?

Re:that thing was slashdotted with under 3 comment

[Chester K]

Either most slashdot readers are now actually reading the articles

It's a new feature of PHP5 ... Anticipatory Slashdotting.

Re:Java? Hardly.

[Fammy2000]

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?

[prowley]

The basis for programming languages is mathematics. Given that, we are doing quite well really. More expressive languages tend to have two downsides that faviour less expressive languages in many a case: 1) they tend to be slower than the same system written in a more traditional language, and no matter how fast processors get, there will always be incentive to squeeze the best performance out of them. 2) they tend to be less general purpose which limits their ability to become ubiquitous. If you have time to learn one language, would you pick a more specialised one which would limit what you could write, or a more general purpose one that allows more flexibility? Those are really the big drivers (or inhibitors) to language take up in my view. Scripting languages tend not to obey those rules but fill the "its either done using a script or it gets done manually" niche, so the performance comparison is different, but still there.

Not doing much to improve my opinion... (/.'ed)

[tweakt]

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

[Bob Bobbinson]

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.

Re:not java

[Phil.Roberts]

An afterthought that they decided to base an entire re-write of the core PHP engine around....

WORKING LINK (for now)

[Thoguth]

http://talks.php.net/show/php5intro

Not trying to karma-whore, I just thought I'd use my +1 for something good because nobody seemed to notice the AC link.

Re:Who cares?

[Lordrashmi]

Are you a troll or would you care to point out all the security holes?

Re:Apache is Dying! Let's look at this months numb

[winkydink]

Can you say "statistically insignificant"?

PHP5 wishlist

[Kunta Kinte]

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.

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.

PHP Is *not* an application server

[tweakt]

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.

Re:PHP Is *not* an application server

[bahwi]

Best reason not to move to Java: click.

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. 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.

Re:PHP Is *not* an application server

[the eric conspiracy]

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.

Re:PHP Is *not* an application server

[Dalroth]

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

[Synn]

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.

Re:PHP Is *not* an application server

[LPetrazickis]

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

Sounds fair. You get the Pinto.

Re:PHP Is *not* an application server

[rollingcalf]

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.

Re:LAMP ... what about JOLA

[MmmmAqua]

Here's what I think...

I work for a company that uses both systems - LAMP for webservers, PJOLA (PHP/Java/Oracle/Linux/Apache) for the internal office/admin/order system, with some interesting interactions between the two systems.

For example, product data and changes originate in the internal system, get sent from Oracle to a MySQL master DB through an ODBC link, then the MySQL master propagates the changes down to the webservers, which are MySQL slaves. The flow of orders from MySQL to Oracle is less complicated, as each webserver transfers its orders directly to Oracle through an ODBC link.

These are just two of the interactions with external data involved in our system (data external to Oracle, that is). Here is why we don't use MySQL internally:

It's not ready for enterprise use. Flame me all you want, but that's the simple truth. Without subselects, built-in OLAP, a comprehensive data dictionary (which is crucial for system auditing), comprehensive tracing features (ditto), hot-standby failover support, clustered database support, and a dozen other things, MySQL is not suited to mission-critical environments.

It's fine for our webservers, where it is important to have a lightweight, fast database server, but not for the really important stuff; I can lose a webserver, no problem - there are several more I can redistribute the load to - but I absolutely cannot lose my office/order system. MySQL can't provide a reasonable guarantee of my data's integrity and security, so I'm not using it.

As for PostgreSQL - when we first started developing our system, we came down to two databases for the internal side: Oracle8i and PostgreSQL. We ended up choosing Oracle for performance reasons, and for clustered database support. PostgreSQL is a full-featured, stable, capable database, but it can't keep up with Oracle for speed or features. Example: Oracle9i's XMLDB - a huge boon to systems which do a lot of business-to-business (sorry, but I hate the B2B B2C, etc. crap) data interchange. Much of today's interchange is done in XML, and the ability to treat an XML file as just another table is a huge effort and timesaver. Oracle isn't the only database with XML support, but it is the only one I know of that allows you to join an XML file to an internal table for queries.

So, flame away, I'm wearing my asbestos underpants. But those are the facts as I see them.

Re:Java by any other name?

[FortKnox]

Just to keep up the zealotous/elitist flames:
I describe C++ as "Assembly for dummies."

Different languages for different applications. I'd like to see you write an enterprise website in C++. Its best to not flame something so ignorantly.

Re:Java? Hardly.

[stonecypher]

> 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 dismissive. PHP scales far better than Perl does. Go talk to the yahoos at Yahoo!. (There are good arguments raging about PHP vs. Java in scalability, and so I won't start that here, as I don't want a bad argument to be my fault. Go read if you want to, but don't just assume that because you can't write scalable PHP it can't be done.)

Re:Who cares?

[stonecypher]

> PHP 4 and previous versions taught most of us
> that if you run it even a 13-year-old script-
> kiddy can 0wn your site.

Unless of course you have another thirteen year old doing security at your site. PHP is arguably just as hard to get into as Tomcat, ASP, or most CGI applications (read: not very difficult at all.)

This has more to do with the software written in the language than the language itself. Yes, I know there have been many PHP security holes; there have been security holes for *everyone*. Progressive squashing is the name of the game, and if you're not QMail, you're part of the problem.

Don't blame industry problems on one language, please. It's obnoxious.

PHP

[www!!!1]

PHP? What's that? If you can't write it in pure assembly, its not worth writing!

Where is the unified database interfase ?

[mxpengin]

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 !

Re:Where is the unified database interfase ?

[Christianfreak]

It does of course it still sucks, its not near as powerful as Perl's DBI but its a start and its much better than stupid_function_names()

Re:Where is the unified database interfase ?

[Monkey]

Have you ever seen the IBM commercial where the engineer shows up to a board meeting and he's got this big ball of connnectors and dongles and shit all connected together? It goes something like this:

CEO: What's that?
Engineer: It's a universal adapter for everything.
CEO: Everything?
Engineer: Yes anything, we've built in support to connect to all possible interfaces.
Executive Peon#1: Does it support European outlets?
Engineer: Umm... <looks at device in dismay>

Re:Where is the unified database interfase ?

[ShotgunEd]

I am waiting PHP can get something like that !
It's called PEAR DB and it already exists... Although, admittedly, it's not nearly as slick as JDBC and not quite as powerful as DBI.

actually, if you read the article

[jbellis]

(here's the pdf) ... 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.

Re:Java? Hardly.

[RevAaron]

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 analogous to SOAP, homebrew and pre-built, text (like SOAP or XML-RPC) or binary based.

(not that it matters, but you are donning the flamesuite, not "dawning" it.)

Re:Java? Hardly.

[kson34]

>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?
When did you last check, PHP3? PHP has had a Java binding, a Corba binding, and a COM binding for years (since early PHP4). And you can extend PHP with C if you need speed (rather than a more robust OO environment), you can even write your c code inline with php (see Inline_C) for a cool pear package.

The added OO features (and more importantly for speed matters, the fact that objects are now passed by reference and not by value by default) are just going to be a bonus. Exception handling will be nice for large projects.

>Just curious, how can you have an object model without namespaces? Or interfaces for that matter?

The objects in PHP where initially just glorified arrays (like Javascript). However, interfaces and namespaces -- useful as they are -- are certainly not necessary for an object model. You can do very nice OO programming in C if you are disciplined enough. You don't really need the language to hold your hand.

Scale

[Synn]

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.

Re:System-wide objects

[Arethan]

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 control access. Of course, you'd need to write it all yourself since I don't know of any existing class to perform this. Even then, nothing comes close to a native solution within PHP itself for speed and reliability. If it's so easy using shared memory, why isn't there already a built in solution using this that is part of the default compile? I'd guess that portability of PHP probably makes this solution useless. Last I checked, SysV IPC wasn't available on Wintel boxes. Sure, the functionality is duplicated within different API calls, but it really isn't SysV IPC.

Don't want to sound demeaning, but I just don't see the practicality of using shared memory for something that should already be included natively. *shrug*

PHP, Java and Problems with new gimmicks

[theolein]

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.

Re:Apache is Dying! Let's look at this months numb

[Lxy]

Sorry, I got in the wrong mind track. Too many "BSD is dying" posts screwed up my already messed up brain.