Introduction to PHP5 343
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..."
Re:Java? (Score:2, Insightful)
Re:And, if you want it right now... (Score:5, Insightful)
jason
Re:Apache is Dying! Let's look at this months numb (Score:2, Insightful)
Re:yikes! (Score:5, Insightful)
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:We need good examples (Score:2, Insightful)
> 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:Java? Hardly. (Score:2, Insightful)
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? (Score:2, Insightful)
> 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.
Re:And, if you want it right now... (Score:5, Insightful)
Re:PHP Is *not* an application server (Score:3, Insightful)
The same could be said for Visual Basic,
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:yikes! (Score:2, Insightful)
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 [amazon.com] 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
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:PHP Is *not* an application server (Score:5, Insightful)
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:3, Insightful)