Re: FW: Bugzilla rewrite in PHP

While most of these criticisms are *somewhat* valid, they're valid only to the extent that the person writing them is not an expert in PHP, but rather Perl. The database thing is beginning to bug me, as it is sort of true, but sort of not. Yes, there are different functions to access different databases. This is what, imo, gives PHP it's flexibility. The databases are different, and have different functionality, and you should be able to access the specific features of each. OTOH, we, as most people, have a db abstraction class that handles most of the routine stuff for us. nextrow(), query(), open(), close(), etc. Changing databases will generally only entail writing new code for those functions, and the main code will remain exactly the same. OK, so DBI has this predone - PEAR does too, although try to get info on it (or use it at an ISP) and you'll have an uphill battle. Once you write it, it's done tho. *PORTABLE* to other projects (the seeming opposite of the criticism that you're locked into 'code in page' architecture). True DB *independance* isn't had by Perl DBI. At least, not in my experience. I *STILL* need to write sql code specific to the database I'm running on. If I was connecting to SQL7, I couldn't use 'limit', for example. So how much benefit something like DBI gives you over something like PEAR or one of the many homegrown solutions is, to me, questionable. <!--#include (Metabase comments)--> :) Anyone with more DBI experience care to comment? The PHP site being navigable - yes, valid criticism. It's getting better, but it's a hell of a lot of HTML (menus, etc) every page. "PHP's support seems to be quite a bit broader" but he can't tell because of the website. Well, how else does it 'seem' broader to him? Word of mouth? Higher visibility? The attack on the design of sourceforce is a redherring, obviously. "The design of large PHP sites that he sees the code for sucks, so PHP must suck." Bugzilla sucks too - that's why people are considering the rewrite. "Well, yes, but..." Come on! "the "script-in-page" concept pretty much defeats effective code reuse." Don't put script in a page then. Use templates. Easy enough. "and each one seemingly has to import about twelve other .php files before it can even start to work" Example Perl script first few lines... #!/usr/bin/perl use Socket; use Net::hostent; use CGI qw(:standard); use DBI; use Net::FTP; use LWP::Simple; Hmmm.... looks like they need to import a lot of files before it can even start to work. "It's caked-on layers of function sets with an obvious lack of direction or design." Sheesh! Could this not be said of CPAN? Not everything in the PHP manual is installed by default, but there are ways of putting most of that functionality into the PHP interpreter. I wouldn't say 'caked-on layers' at all? "obvious lack of direction or design" to me is CPAN in a nutshell. I love CPAN and think it's great, but there's very little 'direction' there, imo. People write modules to solve particular problems and put them out for others to use. Same in PHP. PHP is also easy to maintain as long as you write it that way. I almost didn't write, except that, if only for the list archives, this kind of 'reasoning' needs to continually be dealt with. I know a lot of new people are joining every week and need to be reminded that just because someone from 'up on high' says PERL=GOOD, PHP=BAD, it's not true. Chad Day wrote: > Thought this was amusing and the list might like to comment on it. :) > > Chad > > -----Original Message----- > From: Stephen Clouse [mailto:stephenc@theiqgroup.com] > Sent: Tuesday, November 21, 2000 1:11 PM > To: mozilla-webtools@mozilla.org > Subject: Re: Bugzilla rewrite in PHP > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > If you were given the task of rewriting Bugzilla from the ground up, would > > you keep its existing Perl/CGI based format, or would you use a web based > > scripting language, such as PHP? > > 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. > > It also lacks something crucial to Bugzilla, a consistent database > interface. > 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). 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. > > 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. > > 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" :) > > - -- > Stephen Clouse <stephenc@theiqgroup.com> > Senior Programmer/Systems and Network Administrator > ========================== Michael Kimsal PHP Meta search http://www.phphelpdesk.com/search/ PHP Training courses http://www.tapinternet.com/php