------------------------------------------------
On Wed, 23 Jul 2003 00:59:29 -0700, drieux <[EMAIL PROTECTED]> wrote:
>
> On Tuesday, Jul 22, 2003, at 20:10 US/Pacific, Wiggins d'Anconia wrote:
> > Octavian Rasnita wrote:
> [..]
> >> Of course, he was talking about CGI programming, because I know that
> >> Perl
> >> can do much more than CGI programming like PHP.
> >
> > As much as we jest at your expense I suppose a "real" answer should
> > be given, well other than drieux's long rant about MVC and layers ;-).
>
> first off, I actually wish that the process of WOOFing
> up 'browser neutral' 'html like stuff' WERE simpler,
> { and that there was BUT one DOM, vice 3++ }
> and as such, there are things in PHP that 'simplify'
> some of that - just as
>
But what fun would that be? I mean if we were efficient in our pursuit of what was
possible, rather than just stabbing at it in 40 different methods we wouldn't be
appreciated things like the dot-com bubble, off-shore out-sourcing, and would in
general be a much happier (global) society because we could spend our time drinking
canned crappy macrobrewed beer while playing softball...though I am not sure that is
what you were driving at...
> use CGI;
>
> helps in some cases.... so it really is not a matter
> of jesting at Octavian, as much as it is the HORROR
> that HTTP/HTML/XHMTL/XML/XPATH/XSLT/OtherWordsWithX_inThem
> were not so much 'released' as LEAKED OUT like toxic waste.
>
Actually I meant more myself and the other poster, you we were the ones jesting at him.
> As such we have all been improvising ways to 'woof Up Html Stuff',
Definitely, and I thought it was just that we didn't know what we were doing, or I
guess that is correct, I just thought it was we were the ONLY ones that didn't know
what we were doing.
> [..]
> > The closest answer is "whatever works best in your situation".
> > The problem with this answer is there are at least a hundred
> > different factors in determining what your situation is, and
> > even if you could define it that explicitly there would still
> > be overlap of features, etc.
> [..]
>
> Where this somewhat fails is that I might have argued not that
> long ago that one would be better positioned were one to
> construct the 'perl code' - in modules - as I do, and test
> that the underlying 'controller code' can work as a stand-alone
>
> dumb.plx
>
> that I can run at the command line - and then knowing that I
> can get all of the right information back as an '@menu_list'
> that I could then unwrap into html to show up as
>
> <select name="q_host" size="1">
> <option value="4.01">4.01</option>
> <option value="8049">8049</option>
> <option value="1">1</option>
> <option value="8347">8347</option>
> <option value="2333">2333</option>
> </select>
>
> which I so love - because this is actually an instance of
> "OOOPSIE" - since the same "Named" piece of "foo.cgi" exists on
> the 'remote web-server' - it is just a rev back, running
> an out of date version of the underlying Perl Module, and
> the 'correct' new style one would have done say:
>
> <select name="q_host" size="1">
> <option value="xanana">xanana</option>
> <option value="libex">libex</option>
> <option value="jeeves">jeeves</option>
> </select>
>
> So having a Perl Module didn't save me, and using HTTP
> as the session layer to 'query back to the config host'
> didn't save me from a 'version skew problem'.
>
> I'm not convinced by my own demonstration here, that
> clearly PHP must be better....
>
> I think a part of why the PHP v. Perl 'flame wars' gets
> going is that at times folks change 'cults' for the wrong
> reason. They ran into a problem that was less easy to
> 'code up' in Perl - and because they could use 'fewer
> lines of text' in PHP - that this must mean that PHP is
> better at 'generating' 'web-pages' - hence must be better
> at being the CGI friend...
>
I would tend to disagree with why they "changed" cults, and argue that it wasn't that
one was easier to use to code it up, but more that their situation had changed. Which
gets me directly to my main reason for preferring the two separated, and hits directly
back to the concept of MVC that you brought up originally. If I am developing a site
that is heavily dynamic in nature, but has a number of different formats (views), then
presumably I am not the only one developing it, and the person, read college freshman
who took a class in HTML during summer school because he likes video games and will
work for $8/hr and all the free mountain dew he can drink, who has to code up the HTML
because I am a snooty overpaid programmer, read who actually has a business degree and
ought to be off trying to figure out how to overstate revenues and understate profits
while contributing to a political campaign so my IP will be protected just long enough
so that I can buy an island in the caribb!
ean with the inflated stock price that only the mass media could have caused, who is
to busy writing page long SQL statements and playing with Perl functions to be
bothered with some simple print statements. So to sum up, because PHP is (usually)
embedded in the HTML itself it does take a programmer not to screw it up when all that
needs to change is an image size or alt attribute, which could have been handled by
just about anyone. But now that I find myself working on "real" Perl applications and
only mess with the web to cure my personal boredom it would be simpler for me to just
smash the two together as I am probably the only one who would ever edit my pathetic
excuse for a homepage, in which case PHP might be the right choice. So rather than
one tool being better than the other, I have changed my situation from being in a team
environment to being a real loner. Another example is the "PHP handles session state
easier and doesn't have an interpreter spawning efficie!
ncy hit" argument, but then naturally someone would flame back that mod_perl can
handle all of that and better because it can be used to control the complete
request/response, however finding an ISP that will let you plugin any old handler into
the config file and then HUP the server could be difficult at best, so again the
situation dictates the tools allowed, rather than what is best.
Originally I had access to my own dedicated server with free hosting, mod_perl would
have been ideal (for me) but as soon as that luxury was taken away moving my sites
would have been a nightmare or expensive.
> One of the coolest answers is at:
>
> http://us2.php.net/manual/en/faq.languages.php#faq.languages.perl
>
> where it notes that Perl is a complicated language that comes from
> a time before the web.... whereas PHP was built specifically for
> the web side of the game... Great!
>
Interesting read, though this still rings true for me "PHP is easier to integrate into
existing HTML than Perl." They see it as a bonus, I see it as a hinderance for a
multiple person operation. Situation..........
http://danconia.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
