On Tue, Nov 20, 2001 at 08:15:16PM -0600, Chad C. Walstrom wrote: > One reason. I don't want to have to rewrite libraries that I've > created. If I can't reuse something I've written with any front-end, > then what use is it to me? Maybe PHP isn't right for me, period. You > don't need to stand on your high-horse and sing to the choir. I was > simply trying to give the whole PHP-fanatics a chance to show their > knowledge in deploying their language of choice in many different > environments. isn't there a php user group here in the cities? (I'm sure a lot of them follow the discussion here to, but it might be targeted better there). And I'm not saying that it doesn't belong here - just stating the obvious. (http://www.tcphp.org/) I can understand your reasoning for reusing libraries (good thing!), but how often would that happen when it's two difference things you're trying to achieve? Another thing is, there are tons of scripting languages targeted for shell usage and please don't get it more bloated by introducing php scripts for system tasks either. We're going to end up with having to have both sh,bash,tcsh,perl,python, etc. for even booting your machine. I for one have been bitching for 2 years about debian relying so much on perl as it does; I've broken several boxes 'cause I =needed= something never than Debian could produce and have everything break by perl not working correctly for the code they wrote. It might be good for a development environment where you don't use perl, but if you have to do anything with perl it plain sucks. I ended up having to maintain two different sets of installs until they got it figured out so it worked at least. > There's always C/C++, Python, Perl, and Java to implement libraries > while still allowing for a flexible interface. Yes, PHP is designed for > HTML preprocessing and templating, not unlike JSP. Perhaps, I should > only think of PHP in terms of a front-end, not a back-end. Perhaps > creating a application.so (ala C) to load into PHP would be far better > than using PHP "include" statements. Has PHP lately gotten anything for templating? I sure haven't noticed and all the php code I see has those <?php include 'whatever.php' ?> in them and that's =not= my idea of templating. Is there any real solution to templating in php where the actual content doesn't require having any code in them to call the functions? or require it to run through another script to get it processed? I sure hope JSP has a better solution to templating than what my knowledge of php's solution is. But how much processing of the HTML does PHP actually do? Not much? > Then again... there's the binding of GTK libs to PHP. True, once again > a front-end. The same is true of Python, and yes, even Perl or Java. Yes, true, but why would you want "yet another scripting language" to be on your system? I'm not even sure I'd want to do GTK stuff in perl. Maybe for rapid prototyping it's good enough, but not for something you have to give to others. I think maintaining an install of a machine is going to be so much harder if you want everything people make. > So, why the bias against PHP. Is it simply because the notation reminds > you too much of ASP? Is it because the default output for PHP is to > wrap things in HTML 1.0 headers and footers? What is it exactly? I'm a perl zealot, I can't help it. I don't see how the notation between PHP and ASP are made... I'm more thinking ASP ... JSP!!! EEEK! I hope you didn't mean HTML 1.0. For obvious reasons. -- Thomas Eibner We interrupt this transmission to bring some breaking news! It's been discovered that idiot Ben is also a dumbass!