Re: FW: Bugzilla rewrite in PHP

From: Date: Tue, 21 Nov 2000 20:37:19 +0000
Subject: Re: FW: Bugzilla rewrite in PHP
References: 1  Groups: php.general 
Request: Send a blank email to php-general+get-26515@lists.php.net to get a copy of this message
The guy has some points, but I think that good developers can overcome the "faults" he talks about. In any case, I think PHP is a much better option for web applications than old CGI. > PHP makes for a nice toy language for sites with simple programming or > Web/DB > interface demands, but to me the whole PHP system seems purely whiz-bang. > It > becomes more apparent if you look at their function reference, where the > only > thing missing seems to be a RFC2324-compliant coffee maker interface. It's > caked-on layers of function sets with an obvious lack of direction or > design. > Brooks described second-system effect; this looks more like sixth-system > effect. Feeping creaturism is definitely the controlling factor at work. > The > mutation rate still seems to be very high. Interesting. I've found that many of these functions aren't available (for better or for worse) unless I have specifically compiled PHP for use with a specific module. You can keep your module base pretty small if you want. > > It also lacks something crucial to Bugzilla, a consistent database > interface. Er, ever heard of PHPlib? I'll admit it's not my first choice, but it IS a consistent database interface that's very well-supported. I'd like to see an object-oriented database interface in PHP myself, but PHPlib is easy enough. > Oddly enough, PHP supports object-oriented design, but all the core routines > are function-based. Three different databases, three completely different > function sets. Having to deal with mysql_*, pg_*, Ora*, and OCI* (yes, even > the function name styles are inconsistent) is not particularly conducive to > the > goal of making Bugzilla database-portable. Not to mention that an Oracle 8 > port under this system, having nothing but the raw OCI available, introduces > a > whole new level of pain. Of course, you could write an abstraction layer > for > PHP yourself, but Perl has DBI already. > > You also lock yourself into their supported architectures. I believe this > was > the reason mod_perl was argued against a while back (being essentially an > Apache-exclusive feature). PHP's support seems to be quite a bit broader, > but > I can't really be sure (the innavigability of their Web site doesn't help > the > research much). Eh, no reason to use the website as ammunition against PHP itself. PHP is well-supported on many platforms. And you're still forcing the installation of Yet Another > Component -- PHP is popular, but it's in no way as defacto as Perl, which > seems > to be as prevalent as sh anymore. Keep in mind who's going to be installing > and using Bugzilla -- I can almost guarantee you're going to see far more > corporate hackers already entrenched (not necessarily by their choice) in a > hardware/OS/backend system (not necessarily being their choice). Don't just > assume they can pop in their RedHat CD and have Apache/PHP/mySQL all set up > in > a single command. LOL. Have you heard of RPMs? In any case, it took me a half-an-hour to get Apache (with mod_perl, PHP, and other modules), PHP, and MySQL compiled from scratch and running. > > PHP certainly wasn't designed for large-scale or long-term project > maintainability, since the "script-in-page" concept pretty much defeats > effective code reuse. As a case study, take a look at SourceForge, which is > an > excellent and functional system that deserves praise, but if I were asked to > take over that codebase, I believe I'd opt for the execution instead. There > are 298 .php files in that thing. At least half of those are actual HTML > pages, and each one seemingly has to import about twelve other .php files > before it can even start to work. This is klugy at best, and other large > projects built around PHP don't look much better (some look worse, even). > The > current Bugzilla design isn't much prettier, which is probably why the > rewrite > is being considered. Things need to be centralized, which is easy to do in > the > old CGI paradigm, and especially easy with Perl. I'll admit that OO support in PHP is a bit lacking, but I see no major disadvantage from OO in Perl (although many small ones). You can build a highly modular and centralized web application with PHP classes and mySQL; I've done it. > Perl is easy to maintain so long as you code it that way. Don't feed me > that > ancient argument about Perl resembling line noise. > > I'd keep going but it's time for lunch. I suppose at this point I don't > have > to mention "I think it's a bad idea" :) I adore Perl, but I think that Bugzilla would be much more maintainable and implemented faster in PHP/(insert your DBMS here). Dean.

« previous php.general (#26515) next »