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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 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. Ah, but I'm that particular type of jerk that always has to have the last word :) I wanted to start by noting that before I saw this, someone (actually, I think it was Rasmus, but I don't feel like hunting through my personal mail folder again) showed me what one as uninformed as I might call "the future", aka PEAR, and I have the sudden need for sunglasses. Dunno, syntax like that (and the inevitable functionality implied by it) pretty much shoots my whole argument down. So indeed, I'm actually looking forward to the next major release, when I assume the implementation will be robust and documented. Maybe it'll wean me off Perl...or not :) But it would certainly move PHP to a high slot on my Languages of Choice list. > 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. An understandable one. Perl has about six or seven years on PHP, and this is obviously all new stuff...PHP4 is what, barely half a year old now, and PEAR is still seemingly in the fleshing-out stages. Perhaps in light of that I expect too much. > 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. Sure enough, staring back at my tearful bloodshot eyes (from the recent rash of 18-hour days, no doubt) is the include_path CONFIGURATION setting. And where else would the evil documentation gnomes hide it but in the CONFIGURATION section of the manual. Dear God, I must be half asleep. > 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. This (that is, a database operation) was the exact PEAR example that was passed along to me, and for a minute I thought I was staring at a piece of Perl DBI code pasted by mistake. I can't complain too much after seeing that :) Perlish OO syntax and PHP integration. It tastes great AND is less filling. > 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. Again, there's that six year head start. But who knows what the defacto standards will be in another six.... > > 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. Which, I'll admit, I didn't spend a whole lot of time on. I prefer dirty technical documentation, man pages and their ilk. The php.net docs are right up my alley, which is why they've been essentially my sole source of help. > Again, not in the 'PHP standard site', partially because there are many ways > to achieve it, and each has it's benefits and drawbacks. TMTOWTDI is considered a feature by a Perl zealot :) > 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. Nothing wrong with covering it as a sidebar, though. > 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). Perhaps a good chunk of the "problem" just comes from me being stuck in the Perl paradigm (use WhatIWant) and wishing for the Perlish interface. > 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. Yes, CGI.pm IS monolithic (and even Lincoln Stein admits that, a bug that will be fixed in 3.0). But really, you don't ever use that much of it. The average user gets this far: $cgi = CGI->new; $foo = $cgi->param('foo'); And really, what more does one need? But the rest of it is there if you want it, and we utilize the form element generation functions quite a bit nowadays. They're especially nice because they automatically fill in values from the previous form submit. I find it rather funny, because I said almost the exact same thing when I first got into Perl/CGI :) But I learned something rather quickly: "Your implementation is wrong". And nowadays, I always search CPAN for something tried and true before reinventing the wheel. And from looking at PEAR, it seems that PHP is about to halt its wheel manufacturing operations :) > 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. I do think its sheer size has a lot to do with that. A lot of times it more resembles a code landfill than a repository. I can't claim to be satisfied with every purchase I've made there :) > 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. Ah, but when a CPAN module is just slightly off my target, I subclass it and there bend and tweak it to my maniacal will. I love OOP. > > 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. I think this rant of mine is no longer valid. Not that anyone here is complaining. > > > 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 Unless it's APL :) > 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. I suppose I came off blatantly critical, but I was directing the comments as they applied to Bugzilla specifically (aside from the *painfully* obvious point of, Bugzilla is ALREADY in Perl, why change it). By no means is PHP a bad language, nor was I suggesting it (again, take the mail in its original context, which was definitely NOT this list). There is a very definite gap it fills for me, the (pretty broad) one between static HTML and the obscenely complex e-commerce systems we develop (in Perl and Oracle). > 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). It would seem a lot of it is that. Hopefully one is able to read where to divert extra development energy :) > I do object to your use of 'toy language'. So do I, actually. I suddenly had a vision of whirled peas and punched the hole next to Alice Cooper instead. > 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. I would still differ based on the current (documented) implementation, but as has been noted already, big changes are on the way in this camp. Sure, I'm still passing harsh and cruel judgement (as any hyper-critical language bigot does), but judgements get overruled every day :) > 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. I always thought holy wars were the sole reason programming languages existed :) Well, those and Emacs.... Let's not waste any more of this good list's bandwidth, though. Just know that my opinion has been swayed in light of this compelling new evidence :) Here's to all good programming languages. - -- Stephen Clouse <stephenc@theiqgroup.com> Senior Programmer/Systems and Network Administrator The IQ Group, Inc. <http://www.theiqgroup.com> -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.8 iQA/AwUBOhtf5gOGqGs0PadnEQLrBACg4SdL71Z24OoQbLAePn1gr6pWqrcAoMoU xbAApxR15LW8kXnAKViz+v5t =FjKk -----END PGP SIGNATURE-----