On Wednesday, Jul 23, 2003, at 07:59 US/Pacific, [EMAIL PROTECTED] wrote:
[..]
[..]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.
How about the compromise position, coders change cults - at times for the reasons stated, at times the reason stated is to obfuscate the realIssue[tm].
[..]
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.
It might be Dangerous to start the 'but are perl Coders, RealCoders[tm]' thread as a side bar to this.... But your main thrust apparently is a core part of the problem - how much should an organization invest in which level of 'IT' staff.... If one starts with simple 'static' html pages - then it clearly would be the simpler approach to go with a modest change path, and shift into PHP - if you want to merely 'upgrade in place' - assuming of course that the basic 'site' was kosher to begin with.
[..]
[..]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.
Good Point! Few folks take the time to cover the trade offs in the 'team approach' v. 'I CodeMonkey'...
Allow me the illustration of the three players on the current project -
<http://www.wetware.com/rai/> - did the graphics <http://www.wetware.com/drieux/> - did the middleware 'cgi' sir_URL_not_appearing_on_the_web - spawned the underlying technology
{ i think that the lack of a personal web-page SHOULD be
held against the FREAK.... but the differences between the
two URL's only indicate the delta between asthetics.... }A part of the problem then is how much 'knowledge' can one
stuff into a single codeMonkey, and whether or not that is a
gooder idea to begin with? If one has the luxury of a 'team approach'
then one can break the problem down into constituent parts and
let each hack at their part. Early on, there was this 'optomism'
that we would be able to save most of the original 'demo site'
that was done with I believe Adobe GoLive - but the problem of
course was that it had none of the 'CGI voodoo' inside it that
would allow pages to be built dynamically, nor interact with
each other... The Cooler part was that it lead to an 'abstraction
layer' that then became a perl module, in which we hide all of
the 'this is our basic page' so that all of the cgi.foo code
no longer had to know how that was actually being done - and
also comically, meant that while yes, we were technically using
'cascading style sheets' and yes, that information IS in an
external file - that 'external file' happens to be a Perl Module
that has other smack in it as well... Hence maintenance of that
module meant that all of the Freaking Pages would 'conform' to
the, let us be polite, WEIRD AESTHETIC OF PERSON WITH NO GRAPHICAL EYE.
{ fortunately for me, that was rai's problem.... she had to deal
with getting the FreakingTroglydyte on the same page, I merely had
to code it up to come out that way.... }Ultimately all that would be 'saved' of the original demo were the actual 'icon gifs'. As such, this was not going to be a simple 'upgrade' from an existing set of HTML.
Hence a part of why I wanted to get the MVC part of the dialog into play - since as at least a 'useful design pattern' it will help folks work out 'who owns which part' - and how much of it has to be exposed to whom. The three virtues of perlCoders are
1. hubris
2. impatience
3. lazinessBut at times we REALLY SHOULD look before we leap - it saves on having to come back and 'refactor' the code.... The worst of all Sins in perlCoding is to implement the three virtues wrongly.
When folks recall that PHP started out as 'Personal Home Page' - with the idea that this would make it simpler for folks to spin up their own personal web-pages and has evolved into its own cult following. And we would want to put our profession at risk by remembering that many here started on 'personal computers' rather than RealBigIron[tm]... Or publically talking about the cut over from perl4 to perl5....
Octavian's original query, as I read it, was not so much 'flame bait' - but the expected problem that all coders run into - namely when to use "Which Technology". A question that unfortunately gets the answer
'well there are a lot of factors....'
and it may help folks to sort out their prejudices, experiences, 'fear and loathing' so that other coders can learn along the way.
As you have noted, many of the general arguments get mushy really quickly.
There are many great virtues to mod_perl over merely running stand alone cgi code - but that does not come at a cheap price either. Especially when the 'web application' will require that the end customer get into the groove of actually using 'mini-web servers' such as a bare bones Apache Server in a stand alone mode - without installing all of the gagillion supporting wingDingDingDing options.
So does that negate mod_perl???? Not Likely.
Unfortunately there is no good method by which 'experience' can be passed along,
so the best that we can do is present it - and hope that the
re-usable bits will be understood - even if they mutate into
even stranger ideas at the reader's end.
At the risk of a 'real flame war' - we might be rude and ask what are the real 'software engineering principles' that are actually used to defend Perl from PHP....
Or is a part of the ongoing problem that Perl is the Proof Positive that 'software engineering principles' are strictly for those who just do not have any principles to begin with.
Made all the more unpleasant by the fact that we CAN implement the 'Common Gateway Interface' <http://www.w3.org/CGI/> both FOR 'html' stuff, as well as for non-html stuff... so is the thingie that one's "cgi" going to be doing 'strictly' a matter of dynamically generating 'html'????
Remember that:
libex: 57:] GET -S -e "http://db_host/HqDb/db_mgr.cgi?verb=get_both"; ; echo ""
GET http://db_host/HqDb/db_mgr.cgi?verb=get_both --> 200 OK
Connection: close
Date: Wed, 23 Jul 2003 18:33:23 GMT
Server: Apache/2.0.45 (Unix)
Content-Length: 105
Content-Type: text/plain; charset=ISO-8859-1
Client-Date: Wed, 23 Jul 2003 18:33:23 GMT
Client-Response-Num: 1
jMan=jeeves&store2=vladimir&store3=vladimir&new_style=vladimir&vMan=vlad imir&store1=libex&store4=vladimir
libex: 58:]
conforms to the CGI spec, BUT is not returning anything that is in 'html'...
So clearly we will want to make sure that we work out which part of 'perl cgi' is about the CGI, and which part is about 'woofing up' html to browsers...
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
