Closed Thread Icon

Preserved Topic: The Limitations of PHP (Page 1 of 1) Pages that link to <a href="http://ozoneasylum.com/backlink?for=13070" title="Pages that link to Preserved Topic: The Limitations of PHP (Page 1 of 1)" rel="nofollow" >Preserved Topic: The Limitations of PHP <span class="small">(Page 1 of 1)</span>\

 
Perfect Thunder
Paranoid (IV) Inmate

From: Milwaukee
Insane since: Oct 2001

posted posted 03-03-2004 02:02

A very interesting article about PHP's limitations in serious development work. I've encountered a few of these myself from time to time, and as I work with Java/JSP, I'm getting a better idea of the alternatives.

Most server-side programming I see on the Asylum is small-site programming done by one person, which means that PHP is just fine for that... but if you use PHP seriously, this article may be interesting.

Note, by the way, that I'm not volunteering to start some PHP-vs-the-world holy war. I like PHP a lot. But this article expresses a lot of the things that dissatisfy me in PHP.

Cell 1250 :: alanmacdougall.com :: Illustrator tips

bitdamaged
Maniac (V) Mad Scientist

From: 100101010011 <-- right about here
Insane since: Mar 2000

posted posted 03-03-2004 02:49

Not a bad article. It should be pointed out however that many of these "limitations" are in fact design decisions. They all bring benefits to their drawbacks.

Also many of these can be solved with good best practices. Don't like combining Business and Display logic? then don't combine them. Worried about cluttering the global namespace? Use objects for scope. etc.

Really there's not a lot here he's just stating what most PHP users know.



.:[ Never resist a perfect moment ]:.

DmS
Paranoid (IV) Inmate

From: Sthlm, Sweden
Insane since: Oct 2000

posted posted 03-03-2004 10:51

I agree with bit here, well written, touches on important parts but it doesn't touch on the underlying problems. Project management and discipline.

True, a lot, if not most small to medium PHP-based sites freely mix logic, db-access and presentation. They use globals & superglobals instead of passing parameters in procedural code, they wrap procedural code in classes and call it OOP and more.
Why?

Well, in 99% of these cases the developers do not think and design before they code.
This multiplies the problem by a factor of the numbers of involved developers in the project since everyone has habits and concepts they want to follow when they code.

In my view these concerns that he points out are more an effect of a large project without technical project management and clear, enforced guidelines for development than problems in PHP itself.

Of course PHP has limitations as well when you go into larger projects, mainly multi-tier OOP based ones that needs to scale and be fast. Some that I see are:

- loose typecasting
You can work with manual typecasting for variables but it takes time and it has to be a project wide desicion that is enforced all the way through.

- Passing by copy, not by reference as standard.
If you don't explicitly pass an object by reference ( $myObj = &new myClass() ) there are situations where you do not recieve the result you want, I guarantee it.

- Declaration of private variables & methods in classes.
Any developer can access & manipulate everything inside a class-instance at any time.

- Multiple inheritance
You can only extend one class.

- Lack of an application-scoped object/namespace
You cannot store sessionlike data that every user can use without using external storage

- In multi-tiered OOP projects you get HUGE files that are sent to the run-time compiler if you are not very careful and orgainsed in you planning.
This is important in a performance and scaling aspect, lot's of un nessecarry code to parse before an output is generated.

- Lack of a decent exception handling
Almost forces you to create your own errorhandling from scratch

Granted, some of these things are adressed in PHP 5 that's on the way, and some are aspects of the fact that it is a serverside scripting language. However these things are an issue in the installations that are live out there today.

But still, few of these limitations cannot be handled manually in a project IF the project is well managed and every involved person understands why things should be done in a certain way.

But I would not compare PHP to JSP/Java, just as I would not compare traditional ASP to JSPO/Java mainly since Java is compiled and JSP is precompiled, this makes a big difference compared to a non-compiled language.

In a nutshell, While PHP can do almost everything, it's not for all projects, neither are JSP/Java. It all depends on what tool is best suited for the job at hand and what your developers are most proficient and motivated in.
/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

DmS
Paranoid (IV) Inmate

From: Sthlm, Sweden
Insane since: Oct 2000

posted posted 03-03-2004 23:10

Heh, I just had to pop this article in here.
some of those figures are simply astounding, or what about of "checking 47,173,415 domains, 15,205,474 had PHP installed. That is approximately 32 percent of all domains on the Web..."

Do you PHP by Rasmus Lerdorf: http://otn.oracle.com/pub/articles/php_experts/rasmus_php.html
/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

Cameron
Bipolar (III) Inmate

From: Brisbane
Insane since: Jan 2003

posted posted 03-05-2004 17:59

PHP5 does indeed fix a lot of these issues, I've been playing aorund with it on my development server for the past month and I've been very impressed. The new OO model is *better*, not great but cetainly an improvment. Everything is now passed as a reference, and they've included exception handeling. The new XML parsing & validating, XSL and DOM support allows developers to pertty much completly seperate logic from presentation.

I'm really hoping the new XSL support in PHP5 will trigger a switch to PHP applications using XSL as it's templating and display system. I'm actually in the middle of writing my own publishing system with PHP5, XML and XSL, and I must say it's several factors easier and faster to develope with.

Namespace support was aparently considered for PHP5 but dropped at some point due to performance issues. Perhaps support for this will be added in a minor version update...

It should also be noted that PHP's ease of use and generally function oriented approach offer more advantages than disavantages in light of what PHP was designed for. It's not designed for large scale or enterprise level applications, and anyone developing at that level should condiser using a language better suited to the job at hand.

That article just seems a little like trying to compare Javascript to C++, it's not really written in light of what the language was designed for. And at the end of the day, if you don't like it or don't thinks it's provides what you need, use a different language, most of them are free anyways.

Which reminds me, I should get around to installing Python and having a bit of a play some time soon. I hear it's quite a nifty language.

Tyberius Prime
Paranoid (IV) Mad Scientist with Finglongers

From: Germany
Insane since: Sep 2001

posted posted 03-05-2004 21:48

my trust in anything php was shattered with this (unfixed!) bug report.

Cameron: Python is indeed nifty. Though none of the editors/ides was to my liking, so once again, I'm off to write my own. I've been editing itself in it for the last few days (most of it is written in python), and it's getting nifty as well ;-)

Cameron
Bipolar (III) Inmate

From: Brisbane
Insane since: Jan 2003

posted posted 03-06-2004 04:50

I'm one of those people that likes to use the same editor for every program. Althought I must admit at times it feels a little raw. I've been meaning to look into IMB's Eclipse, as I've heard lots of really good things about it from developers working in many different languages.

Heh, editing the code for a text editor, using the text editor your currently writing. Now there's a mind twister for those still polishing off their first coffee for the day. Would you call that recursive editing?

Tyberius Prime
Paranoid (IV) Mad Scientist with Finglongers

From: Germany
Insane since: Sep 2001

posted posted 03-06-2004 10:26

nah, that's bootstrapping.

And I too tend to use the same editor... once I'm done with implementing all the python niceties, my php editor and python editor will again merge. (The python one is basically a fork of the php one, minus all the php stuff ;-))

Trigger
Paranoid (IV) Inmate

From:
Insane since: Jun 2002

posted posted 03-13-2004 10:30

Do you plan to release it TP ?

Tyberius Prime
Paranoid (IV) Mad Scientist with Finglongers

From: Germany
Insane since: Sep 2001

posted posted 03-13-2004 11:40

well... yes and know.
For one thing there are already a couple of people using the php version, but I am way to lazy/busy to create an actual webpage for it.
It's hosted in a subversion repository on a server of mine, and I'm willing to give (read only) access to any one who asks, and write access to anyone who contributes.

This also makes it darn easy to get the a new version. just tell your subversion client (I use tortoisesvn to update the directory, wait, done.

So, if you're interested in either one, the php or the python one (python one is beta - meaning lot's of things are still missing, but I'm using it on a daily basis), drop me a line.

(oh, there's also an email announcment list. Not that I sent lot's of stuff over it, but sometimes, when I've done something cool, I tell everyone to fetch the new version ;-))

« BackwardsOnwards »

Show Forum Drop Down Menu