PHP5 Co-Creator Interview
mandozcode writes "I came across an interesting interview with PHP co-creator Zeev Suraski at Open Enterprise Trends on the latest upgrades for PHP5's First Release Candidate (just released a week or so ago). Sounds like lots of improvements to help make it in the enterprise, including better bundled support for SQLlite and XML. Also encouraging, looks like Zend is getting more millions in VC investment."
If you enable PHP on your apache server, all PHP runs as the same user. That means any files writable by one PHP script are writable by all PHP scripts. There's no such thing as a secure apache PHP installation unless you run in feature limited mode which breaks virtually all PHP scripts and makes it unusable for most tasks.
Until PHP adds suid so PHP runs as the user owning the script, it's a no-go. Run in high security mode it's usable as a toy at best, or run in default mode, it's a security nightmare.
I've spoken with the PHP developers about this at several conferences. Their solution is that you have each user run their own copy of apache or have each user create their own PHP installation and run everything as CGI, launching the local PHP copy. I'm sorry, but that's insane.
I don't give a lick about new features if you can't get the foundation fixed. Take care of the wet sand base before you up the supported database count or make grand announcements about clever new scripting keywords.
The idea of being able to manipulate store retrieve and execute on the fly is currently blowing my mind. I can't wait to get started on it. This is truly groundbreaking
Bring on the Lang X has had that for years
Yea, with a lot of lame hacks you could have done this with a file structure with php itself. But this sounds seamless.
Since its inception, PHP has gone from a simple website templating language and form processing tool, to a semi-OO scripting language hacked onto a bunch of C extensions, and now they expect to become a fully OO, enterprise-ready language?
Scary.
To write web applications properly and efficiently, you need a framework to support you. You do NOT want to be reinventing the wheel. Have you noticed the massive proliferation of database abstraction layers, incompatible form processing libraries, etc. etc. all written in PHP for PHP developers? Libraries of code written in a templating language! Eep. Every reasonably experienced PHP developer has probably tried to create an application framework at some point - if people keep seeing the need for one, it's a good bet PHP needs to supply one. No, PEAR is not an application development framework.
And what is it with all those PHP developers who seem to think a "class" is another term for "static function library"? The concept of using object types is foreign to thse people - they'd rather make huge monster arrays.
Just because the "I Can Use A Database So I Must Be A Web Developer" crowd thinks every web app could and should be written in PHP does NOT mean that that's actually the case.
PHP downright _encourages_ beginners to embed application-logic in HTML pages. I've been through a rewrite of an absolutely MASSIVE PHP site, and it was a year-long affair for five developers. The old site had become impossible to maintain. Talk about a waste of resources.
When PHP adopts a *standard* way of separating content logic from application logic, and enforces that split (kind of the way JSP pages work with servlets), then _maybe_ there will be some hope for it in the enterprise. Until then, Java will continue to dominate. I find it funny that Java interaction is such a high priority for PHP - if Java's installed on a company's hardware, a developer's natural reaction would be to use Java, not write something in some other language.
You don't need a "templating engine" to gain that separation. You need a standard, well understood way of organizing your PHP application, and some libraries of code to support that method of organization - that is, you need an application framework. And PHP sorely needs a *standard* one. It may not be the language developers's job to create it, but it would certainly boost PHP's image if they did - imagine the flood of nice, interoperable applications that would emerge!
CPAN is not a framework, it's a massive library of code libraries, same as PEAR on the PHP side. Code libraries are good, but they don't define a way of structuring your application.
Perhaps one of those frameworks you mention will become a standard, but as long as they implement 'templating languages' I'm not going to hold my breath. PHP may be going in the right direction with the new stuff in Zend 2, but it's still way off the mark for serious webapp development.
I mean, let's get serious, Perl allows GUI apps with Tk, writing your own custom servers, parsing local files via command prompt and what not
p hp
PHP GTK - http://gtk.php.net/
Sockets for PHP - http://php.net/manual/sv/ref.sockets.php
PHP Process Control Functions (fork, etc) - http://php.net/manual/en/ref.pcntl.php
PHP Functions to Parse Conf/Ini Files - http://php.net/manual/en/function.parse-ini-file.
PHP also builds a CLI (command line interface) everytime you compile it enabling you to do perl style #/usr/bin/php and writing command line scripts (even full argc/argv support).
I'm a PHP developer - I do not think "Perl sucks" but I do think developing web applications on PHP is quicker and easier (for me) than in Perl, especially since I'm a native C coder.
To each is own.
...using n-tiered when it suits the domain (just finished a rather tasty J2EE system for a large client). Even a fairly complicated e-commerce engine can be done quickly and efficiently in PHP though if it's being done by someone who has years of "real programming" experience, not someone who comes along and hacks together a personal webpage or pet project (which invariably requies register_globals to be on, yuck).
There is a framework out there that is proven, reliable and very easy to start using, it's called Fusebox.
It has increased our productivity, encouraged code-reuse (instead of write-once never touch again hacks) and meant we get every single project out of the door on time and under budget.
And now with Smarty being taken under PHP's wing so to speak (http://smarty.php.net) you can truly separate display from business logic in a nice simple way.
But once again it comes down to this: Use the right tool for the job! I would never think of using PHP to power an online banking system, but then again I wouldn't use a 3-tiered enterprise system to run a bulletin board.
I am NaN