Re: FW: Bugzilla rewrite in PHP (large post)

Stephen Clouse wrote: > I suppose this will teach me to use that "the following is my very conceited > opinion" header more often. I also must have become confused and accidentally > punched the hole to grant permission to have the post forwarded to > god-knows-where. Either that or I voted for Gore, or something. > > Someone asked for opinions concerning *the Bugzilla project* and I related my > opinions in that context. Why the hell some bonehead felt it was necessary to > carry it over to a PHP advocacy list is beyond me. But I seem to be stuck now. > I don't know why it was carried over either. You replied to my remarks, and I wanted to clarify a few things. I understand you're 'out of the discussion' now, and I'm not expecting a a response, but did want to clarify some points nonetheless. > > > Yes, there are different functions to access different databases. > <snip> > > criticism that you're locked into 'code in page' architecture). > > So some people create PHP modules. I wouldn't doubt that. But these things > hide where? Where's the PHP equivalent of CPAN? You can't hardly work with > Perl without knowing what CPAN is, it's discussed in just about every perl > manpage and book. Resources like that should not go very long without being > prominently mentioned. > This is a problem. There are many disparate code repositories, but nothing centralized as of yet. The PEAR repository may fill that void in the future, but it is a gap at this stage. > > But even then, I'd have to say that you're still relegated to the inelegance of > copying that module everywhere you need it, rather than sharing it from a > central module library (at least, there is no language-level facility for this > - -- certainly I could throw something together on my particular machine to > simulate the Perl @INC array, but that would be just my machine). The > inefficiency of the former model should be readily apparent to anyone who has > either Perl or a /usr/lib directory on their system. And this is where the > criticism comes from, everything has to be duplicated, from the library itself > to the line that imports it into every page. > There are standard 'include' paths which can be set in the .ini file. Back to the centralization issue - it's not set to anything by default. It would be up to the sysadmin to set it to wherever the library directory would be. Functionality is there - it's not always implemented. > > > 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. > > The problems described are the fault of the SQL servers themselves, not DBI or > PHP. I should still be able to code in a way that minimalizes recoding when > I'm ready to port to another database, which DBI does. And assuming that I've > stuck with SQL-92, I CAN take that same program and just change the database > driver parameter, and run it on the new platform. I've done that before, > successfully. Honestly, the differences between the syntaxes of the major SQL > servers, at least in the realm of SELECT/UPDATE/DELETE, are minimal to zero so > long as your schema is properly normalized. And now the consistency of the DBI > interface shows its real benefit. The prepare/execute/fetch model of DBI is > universal, no matter what database I'm using. And the consistency of our DB classes (and others) shows similar benefits. This is a shortcoming of PHP to the degree that it hasn't shipped with something equivalent for some time. Only in the past few months has PEAR been shipping with PHP distributions, and I think it'll be some time before people are comfortable that it'll be in their installations, and that people writing books will assume it's there. Similar to the ADO object in ASP. There *are* ways to achieve this in PHP (multiple ways, actually, and many quite evolved) but nothing has shipped as 'standard' until recently. A whole generation of PHP people have 'grown up' without it, and it'd take some 'unlearning' to switch to a single standard, if only for documentation and traning's sake. > > I suppose I'm just lazy (I can hear the replies to this now -- God forbid we > make you write a PHP abstraction layer). But one still wonders why, with all > this database support in PHP, that no one ever considered a standard interface > to be necessary. > > > "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 documentation spits out a whole list of supported Web servers. One has to > assume that there's broad platform support there as well, but who knows? > Nowhere can I find a list of known working or non-working platforms. > Valid point. A lot of this stuff is still buried in files, etc. "Working/nonworking" does change all the time (with more working every month). Perl's biggest advantage here is that it's pretty much installed on any system you use (save W32). If you had to go through as much effort to install Perl as you did PHP, the popularity of Perl might be a lot lower. Not meant as a cheap shot, just an observation. > > > 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! > > Do you always create broad statements where there are none? Geez, and I even > started out saying "as a [singular] case study", too. Written in haste and not quite finished before the 'send' was hit. Your statement seemed broad, even though you did preface it with a 'single case study' comment. > > > "the "script-in-page" concept pretty much defeats > > effective code reuse." Don't put script in a page then. Use > > templates. Easy enough. > > Document what you preach, then. There's only one method I see in the manual. > I do, for our clients. Enough has been written about templating on many lists/sites. Again, not in the 'PHP standard site', partially because there are many ways to achieve it, and each has it's benefits and drawbacks. Not necessarily a bad thing, to not support an 'official' templating system, but it certainly doesn't make it easier for newbies, I'll admit. > > > "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. > > Okay, so I'll admit that point wasn't well thought, and more specific to the > implementation (SF) than the language. But there's something about it that > just makes it "feel" far less clean than importing standard Perl modules. > Perhaps it's simply that Perl *has* standard modules. Many of the ones I mentioned above *are* standard functions built in to PHP (no need to compile in). HTTP GET requests, FTP support, sockets (actually, maybe you do have to compile --enable-sockets). Difference of opinion here, obviously. To me, it *feels* cleaner to include files that either I wrote, or installed, which are small and do just what I need. CGI.pm is a big monster, and, imo, unnecessary if all I want to do it get the GET variables into an array. > > > 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. > > I don't see how you can look at something like > http://www.perl.com/CPAN-local/modules/00modlist.long.html and > argue that it > has no direction. There seems to be plenty of direction. It's merely an > extremely horizontal market. > I like CPAN (said above). It is organized a bit more accessibly than, say, the zend.com code snippets area. And there are some benefits to it. It still doesn't *feel* like it has 'direction' tho. It still *feels* to me like a bunch of code snippets that I need to install, then test out. Biggest issue with CPAN, and actually just code repositories in general, is that even when something describes conditions close to what I need, it almost always doesn't actually do what I need, and I either need to spend time figuring out someone else's code, or just write something myself. > > PHP, OTOH, compresses that horizontal market into one monolithic function list. > But that's more from the lack of namespaces than anything. One might consider > that a flaw, too. It's where the seeming lack of organization comes from, > anyway. > > Even setting namespaces aside, you obviously have the OO support (that is > well-documented) -- why aren't you leveraging it as part of the core? Fully > function-based interfaces are painful, particularly to my Perl side. Better > yet, do what CGI.pm does -- offer both with a simple switch. Huzzah. > > > PHP is also easy to maintain as long as you write it that way. > > I didn't say it wasn't. I threw that line out as a repellant toward the > inevtiable comment concerning Perl's syntax, which seems to be some kind of > end-all anti-Perl argument. Indeed. :) *most* languages are easy to mantain with 1. liberal comments and 2. decent structure > > > 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. > > Precisely where did the idea come that I'm "up on high"? As if I'm some > kind > of Perl demigod/evangelist. The Perl community at large doesn't even know who > I am. I just program for my company, in whatever language is deemed > convenient. That line wasn't intended directly at you, but at a recurring attitude - it crops up on this list and others from time to time. "My colleague says that X is awesome and PHP sucks" (or something else sucks). It was meant more as a general wakeup call to people (preaching to the choir actually) to think critically about the tools used, and use what is best for the job. "best" is obviously subjective, but thought still needs to go into it. > > PHP has plenty of uses, and I do use it where I find them to be simpler than > Perl. I don't find projects like Bugzilla to be in that category. And as I > said at the top, my "reasoning" was in regards to Bugzilla. In that context, I > like to think I'm right (since I've designed innumerable systems of similar > scope and scale). You act like I set out to slander the Koran. Understood. I wasn't really replying to you, but the arguments 'against' PHP, which as Rasmus pointed out already, are *more* related to documentation than anything else (although structurally you obviously still find flaws). I do object to your use of 'toy language'. Every language is unique, and PHP has proven itself to our projects time and time again. If you've devoted years to Perl, of course that makes most sense. But for others who've used PHP for years, and have watched it grow and mature, it's a hugely capable platform that is more than equipped for handling large web projects. > > But anyway, this is all (like the first time around) just my very conceited > opinion. If you find it flawed, please call someone who cares. With that, I > am done with this discussion (that should have never happened in the first > place). > I'm replying to you as well to indicate that there was no malice intended towards you personally (whether or not you care). We obviously disagree, and don't even know each other. But as your post was made public, and there was an impression that I was attacking you personally, I wanted to set the record straight. > > - -- > Stephen Clouse <stephenc@theiqgroup.com> > Senior Programmer/Systems and Network Administrator > The IQ Group, Inc. <http://www.theiqgroup.com> >