MVC - the 'meme drift' was Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[drieux]

On Wednesday, Jul 30, 2003, at 06:28 US/Pacific, Ovid wrote:
[..]
hi ovid, et al,
let me first start with a bit of Dan Akroyd of SNL fame,

	"Ovid, you spawn of a hairless ape"

The good news seems to be that we DO agree that a root
cause analysis of the 'MVC as meme' can be laid four
square upon the 'Gang of Four' - as you call them,
and were I not lazy I would actually haul down their
tome and cite the ISBN
[..]
if people are learning about MVC from the discussion on this list,
it is probably a good thing that they know a bit of the history of
said pattern rather than assume that it was coughed up from the void
fully formed in the way that it's being discussed on this list.
But I am s not sure that the history will help the discussion,
in part, since the 'meme' has drifted and gained a sense of
orthodoxy all out of proportion to the underlying argument
as you note with:
I am not saying that the GoF presented the only correct view of
how MVC should work (in fact, I object to a common interpretation
that DP can only be used for OO languages).  However, the original
point of Design Patterns (the architectural ones preceeding the
programmatic ones) was to give people a common vocabulary so they
can discuss a situation and know what each other is talking about.
A part of that problem is the presumption that 'OO' provides some
mystico-religious solution that is inherent in the 'language'
rather than that the ideas have been implemented 'better' or 'worser'
in this or that 'programming language'...
Which of course is the Really Comical tid-bit in the midst of a 
kvetching
about PHP v. Perl

Unfortunately, at this point in history, I fear you are being
a bit optomistic that "Design Patterns" were intent upon
providing a common 'vocabulary' - as much as to generate
buzz, and from that buzz to 'sell product' that 'implemented'
a given variation of the meme in drift...
While I may be merely being pessimistic in my interpretation.

We do at least agree that the myth of legend is that the intention
was to produce UML - the Universal Modelling Language - and that
it would provide the one true, formal, and applicable language in
which the TrueBelievers were going to build the great Tower of Babel
based upon the correct implementation of the MVC Design Pattern...
{ this might not be the polite point in the chat to note that
'design pattern' is a buzzPhrase ripped off from other fields
of human endeavor outside of the 'computing world'... and that
the hope underneath the UML/MVC, Design Pattern, et al, was that
we would successfully replicate the 19th Century Notion of the
Factory System in the information age... but that way may be
a bit more unpleasantly complex in its relationships than we
would prefer to cover here... }
[..]
If the people on this list are handed a version of MVC for the
Web and have no idea of the history and origins of said pattern,
then someone who only knows it from the GoF description is going
to have a very confused conversation with someone who doesn't
know the GoF description.
Which of course is the Ultimate Irony of the whole FREAKING Problem.

If a 'design pattern' were suppose to be the portable intellectual
abstraction of a given 'class of problem' - independent of the
actual underlying implementation specific details - then the fact
that we have two groups who come to the same 'design pattern' and
lose the ability to talk about what is merely an abstraction because
of the differences in the underlying implementation specific details
leads me to wonder if the vary concept of a 'design pattern' was,
well, 'weak' and/or 'lame' to begin with Hence my concern that
it was merely 'marketting speak' to bring in new converts to the
cooler cult... rather than finding "God's True Divine Will"
No either description is necessarily good or bad, but they have
significantly different implementations and that's an important 
difference.
[..]

The question then becomes can 'abstract ideas' be ported
around from system to system? Anyone who has dealt with
say Java's
	try{}throw{}catch{}

structure of course has the giggle moment in the discussions
about the differences between ErrorClasses and ExceptionClasses,
since, well, it's not too clear how to manage the 
ErrorClassForCoreDump

Yet, we have seen things like FatalToBrowsers provide a way to
'catch' the 'die' that was 'thrown'{ or should we have said
that 'the die is cast' }
So either we can decide that a 'meme' in it's original intention,
such as the MVC Design Pattern, is worth at least knowing about
and working out how best to use the 'best practices' that it
attempts to establish - or we should follow the 'meme drift'
and decide that Perl Is Dead, because
	NewCoolerCodingFooIsTheWave

So I will fully support you in the war against 'meme drift'
since good ideas remain good ideas, even if they are not as
easy to implement in any given coding language...
and of course, as we all know from the hot buzz 'meme drift du 

Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[Ovid]

--- drieux <[EMAIL PROTECTED]> wrote:
> Ovid,
> 
> I love the smell of 'primate-ism' 
> 
> It could be merely the way that you are presenting the
> problem - and a desire to defend an anachronistic model
> of MVC, based upon the underlying 'primate-ism', and
> the scary thought of 'recursion' in conceptual models
> that might mean sticking the primate in a chair, and
> leaving the heavy lifting to sentient life forms.
[snip]

Hi drieux,

Clearly I need to read my email more frequently.  It looks like there was a bit of a
miscommunication and in rereading what I originally wrote, I think the problem lies in 
my assuming
too much background information and, as a result, not explaining as much as I should 
have.  I've
been bitten by that before and I can only apologize and offer the following 
clarification:

The only point that I was intending to make was that the MVC model that people discuss 
had it's
roots in the MVC model as described by the GoF (Gang of Four -- the "Design Patterns" 
authors) and
if people are learning about MVC from the discussion on this list, it is probably a 
good thing
that they know a bit of the history of said pattern rather than assume that it was 
coughed up from
the void fully formed in the way that it's being discussed on this list.

I am not saying that the GoF presented the only correct view of how MVC should work 
(in fact, I
object to a common interpretation that DP can only be used for OO languages).  
However, the
original point of Design Patterns (the architectural ones preceeding the programmatic 
ones) was to
give people a common vocabulary so they can discuss a situation and know what each 
other is
talking about.

I'm sure plenty of us have had conversations where we say "foo", the other person says 
"foo", but
the conversation goes nowhere.  That's quite often due to each person having a 
different
conceptual idea of what "foo" is.  If the people on this list are handed a version of 
MVC for the
Web and have no idea of the history and origins of said pattern, then someone who only 
knows it
from the GoF description is going to have a very confused conversation with someone 
who doesn't
know the GoF description.  No either description is necessarily good or bad, but they 
have
significantly different implementations and that's an important difference.  
Considering that
another name for the MVC pattern is the "Observer" and that the term "Observer" 
doesn't make much
sense when using the Web, I think that's important to know.

In other words, if everyone starts using similar terms, they should have similar 
meanings or at
least know where their definitions differ.  That's all I meant.

Sorry for the confusion.

Cheers,
Ovid

=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid   http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[drieux]

On Monday, Jul 28, 2003, at 12:24 US/Pacific, Todd W. wrote:
[..]
Remember, I am of the "this AND that" philosophy, so you can walk, 
run, dirt
bike, or staddle two bandwagons at the same time if you like, and, as 
long
as you get where you are going, I will agree that it was done 
correctly.
[..]

The challenge as we all understand is
how to 'understand the actual technology'
whether perl, php, java,  and
how to glue the correct ones together...
Especially given the 'evolution' of XHTML,
et al, and the chances that the 'new buzzWidgetWingDingDingFoo'
will actually be implemented in 'the browser'
I actually did note the

Also, I hope youre reading, as qoted that,
 "I WOULDN'T like to call it the
canonical perl MVC pattern..."
[..]

but well, you know, it wouldn't make a good rant
if one were too constrained by the mere facts.
I shall also have to peek at the AxKit - eg:



yes?

and again, of course, the usual problem of

what is suppose to be on the server-side
as opposed to what is suppose to be on the client-side
and how do we go about solving those sorts of things.

As well as whether or not we can provide

"The "Semantic Web" is coming to a browser near you
(real  soon now ;-). One of the biggest academic concerns
about the web is the lack of semantic content."
and this in an article dated March 13, 2002

{ would this be the wrong time to talk about '64-bit
architectures' - and whether or not one should be
planning on getting that new cool CPU with the fully
implemented 64-bit kernel }
Or would that be in the same space as why we must
all abandon perl5 because perl6 is the hot wave???
ciao
drieux
---

Irony? What Irony?



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[Todd W.]

"Drieux" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> So you will forgive me if I do not opt to jump onto the
> new band wagon that 'all developers' should wax their
> surfBoards, because  is the Next Big Wave that will
> solve all problems end to end, as I will counter, your
> counter to my counter below...

Remember, I am of the "this AND that" philosophy, so you can walk, run, dirt
bike, or staddle two bandwagons at the same time if you like, and, as long
as you get where you are going, I will agree that it was done correctly.

>
> { not that I am being merely contrarian... }

you? nah!!! =0)

>
> [..]
> >> p4: given that hacking in perl does not require MVC as
> >> a design pattern, but one can learn the hard way to support it
> >
> > We have AxKit, but I wouldnt like to call it the canonical perl
>
> I so love the fact that slowly but surely the One True Perl Orthodoxy
> is finally being able to create the canonical perl .
>
> 

I meant canonical as in "the ususal way one accomplishes something" rather
than "the perl god's doctrine on how to accomplish something" As we perlers
know, when we ask the gods how to do something, they start uttering, as if
in tounges, "timtoady!", something we perl diciples understand as, "theres
more than one way to do it."

Also, I hope youre reading, as qoted that, "I WOULDN'T like to call it the
canonical perl MVC pattern..."

>
> > MVC pattern. Most familiar with it probably would though.
> > ASP.NET has MVC with its "code behind" concept.
> >
> > Im not aware of any other MVC based platforms right off.

Todd W



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[drieux]

On Sunday, Jul 27, 2003, at 20:03 US/Pacific, Todd W. wrote:
"Drieux" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
[..]
But First off - COOL RANT!
I was hoping that _some_ day I could string a few sentences
together as well as you do =0)
[..]

flattery will get you out of some problems,
but practice and perceverance is a better strategy
[..]
I agree, as long as you agree that the more one
understands the CS theory,
the less voodoo there is in the implementation.
IF and only IF 'understanding the technical stuff'
from comp-sci really is useful for the 'implementation phase'.
May I recommend "Real Genius" (1984) as an alternative
study in the problems of 'science v. technology'. Given
that basically most of the current 'academic work' in
"computer science" is running anywhere up to a decade
back of there the 'technology' is in industry - the
New Guy on the block may be better served to 'get a
gig' and hang with the BigGeek, Buy the Books, read
them, rather than eat them, and do their own 'experimentation'.
Given some of the stuff that we have seen come out of
the academic discussions about this, that and the next thing,
I am also not at all sure that some of the 'implementation'
is really worth the candel.
One might argue that the Java adoption of 'templates', which
they call 'generics' in the hope that most folks are not going
to notice the absorption of the C++ effort to work around the
problems and unpleasantries of the 'multi-pel klass inheritence'
model that was suppose to be fixed in 'java' with it's extends
and implements, efforts to keep Java out of the FoxWorthy set
of jokes about 'family trees with more than one loop in them'
Uh, well, establishes that some academic debates, when they get to
the implementation phase, do not always add 'value' in the way
that everyone was hoping they could/should/would
In like manner, the fact that one CAN make PHP stand alone 'scripts'
that are not specifically used to create HTML web-pages, would
establish that... one SHOULD implement things that way?
Or would it be simpler to restore the kinder, gentler, more simpler

	'strongly typed v. weakly typed'

computer language academic debates in this space and decide
that we should always follow the Ivory Tower
[..]
I think that most languages are supportive of MVC as a design pattern,
[..]

as well as many other techno-babble-phrases...

would it be impolite of me to raise the scary support for the
phrase 'refactoring' rather than 'recoding' since the former
sounds less threatening to both other coders and mangelment.
while they are, mostly, dealing with the reality of needing
to 'recode' Either because they did not start with
any design pattern save 'the big ball of mud'
I had this glob of code,
and I globulate more code on it
or as a part of the naturual selection, they have come back
to the code and gone
"YEE, that so smells, if my professional peers
were to peek at that, they would make rude noises
in my direction and ask me if my mommy dresses me funny"
drieux to UnterStumpenFumbler
c. 2003, all rights reserved
{ yes, you will have to formally cite that with full legal
attribution, since, well, yes, I am the author of it,
and I plan to defend my IP, even if my mommy does dress me funny... }
But as I believe it was Ovid noted, there are 'meme drifts'
where a 'token' started out actually exporting meaningful content
and simply decays into the 'KultBuzzPhraseDuJure'
So you will forgive me if I do not opt to jump onto the
new band wagon that 'all developers' should wax their
surfBoards, because  is the Next Big Wave that will
solve all problems end to end, as I will counter, your
counter to my counter below...
{ not that I am being merely contrarian... }

[..]
p4: given that hacking in perl does not require MVC as
a design pattern, but one can learn the hard way to support it
We have AxKit, but I wouldnt like to call it the canonical perl
I so love the fact that slowly but surely the One True Perl Orthodoxy
is finally being able to create the canonical perl .


MVC pattern. Most familiar with it probably would though.
ASP.NET has MVC with its "code behind" concept.
Im not aware of any other MVC based platforms right off.
You will forgive me the comedy of giggling at you,
nothing personal you understand, but we have watched
	UML - universal modelling language

evolve from the academic discussions about the
need to have a common 'tokenization system'
to the supposed automation of
'write it in UML,
turn the crank
and out comes code'
Without always pausing to answer the question,

Ok, so this idea can be discussed in an 'OO'
manner, does that mean that it MUST be implemented in

and hence also by extension, the fact that 'foo' implements
the 'bar' can

RE: PHP vs Perl

[Scot Robnett]

> A language which I need to fight a lot with in order to find the right
syntax
> for doing something is not a very clear and easy to use programming
language.

What are you fighting with? I don't really
understand this point - if you want to talk
about languages that place a lot of
restrictions on you and *require* you to
do things in one way and one way only,
try C++ or Java. One of Perl's huge
bonuses (and also a huge down-side),
is that there are so many ways to get
the job done. If you think that having
10 different ways to accomplish the same
task makes it "not very clear," I guess
you're right...but I like the flexibility.



> I also like that there are some prebuild packages that contain Apache,
MySQL
> and PHP configured in such a way that they all work very nice. There is no
such
> a thing for Perl.

Of course there is. The web hosts I work with all have
Perl, MySQL, and DBI installed. Works beautifully.


> It is not very easy to install support for SSL,

Net::SSLeay


> or the library  for creating images for perl

Image::Magick


...

Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]

- Original Message -
From: "Scot Robnett" <[EMAIL PROTECTED]>
To: "Octavian Rasnita" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, July 27, 2003 8:35 PM
Subject: RE: PHP vs Perl


I think there are a couple of myths that need to be cleared up from that
post.

First, the idea that PDF manipulation and secure payment modules "don't work
very well" in Perl. If one has had difficulty in making the modules work for
them, it does not necessarily mean that the module is at fault - in some
cases it might be, but typically I've found that when a module isn't working
for me, I've usually missed something.

Second, the idea that most of the new work can be found in PHP and ASP is
not necessarily the case. The tech industry has taken a hit over the past
few years, and if you're looking at the job boards like Monster, maybe most
of what you *see* is slanted toward Microsoft technology. PHP and ASP are
pushed at corporations because somebody at a high level in the chain has
been told these are the widgets they should use. Trust me, I worked for one
of the major telecom players for 6 years, and I've seen how the buzzwords
work themselves into the hiring process.

However, in my business (I deal with small to medium-sized companies),
they're not concerned about what technology I use as long as it works. So
far, the language that makes most of my projects work is Perl.



-Original Message-----
From: Octavian Rasnita [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 1:38 PM
To: [EMAIL PROTECTED]
Subject: Re: PHP vs Perl


I think the reason why PHP is used more and more much than Perl is that for
CGI related programs it is much simpler to use than perl.
For example it has a set of libraries for the most used functions in a CGI
program, for example SSL support, a module for reading and creating PDF
files, modules for accessing some payments operators for shopping carts,
etc.
Those modules can be created in perl, but even if some of those modules
exists for perl, they don't work  very well. I've tried to use the modules
for creating a PDF document under Windows, but with no success.
It is pretty hard to install some of the perl modules under Windows because
most of them need to be compiled, need a compiler to be installed, etc.

With PHP it is much simpler to work and I can see this even though I don't
know PHP at all yet.

The motivation for new perl learners is not very big because most of the
jobs can be found in PHP/ASP and only after that in perl/Cold Fusion.

I hope Perl 6 will have much more standard modules and the modules from CPAN
will be able to be installed without compiling them with a local compiler.
We should keep in mind that even if the most web servers are running under
Unix/Linux, most computer users and possibly web developers are working
under Windows and the CPAN modules should be all compatible with Windows
also,  and not only with Linux.

Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]

- Original Message -
From: "Todd W." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 24, 2003 11:26 PM
Subject: Re: PHP vs Perl



<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> > 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 g

Re: PHP vs Perl

[Gunther Birznieks]

Octavian,

In some respects I believe you are correct. Here are my 2cents...

1) It is really not good to enable mod_perl by default. Doing so would 
dramatically increase the size of the Apache binary. Enabling all 
scripts to run through Apache::Registry would break half the scripts 
that exist out there... Even the more backwards compatible form of 
Apache::Registry is going to require tweaking for probably some scripts 
and in the meantime would create a support burden for the ISP for sure 
as well as increasing the ISP memory requirements.

Also, mod_perl is a tool with access to Apache internals which can be 
security problem also (so that part would have to be turned off). 
mod_perl is more designed for power users. I do think that a beginner 
can be proficient without too many weeks of work but not the same 
learning curve (like 1 day) as plain CGI/Perl.

2) PHP has some very rich on-line resources available that also furthers 
the helping of people. mod_perl has tried to do the same but only since 
maybe last year or so? My dates may be wrong, but I saw this PHP vs 
mod_perl discussion on the mod_perl mailing list.I think most people 
looked at perl.apache.org THEN, and PHP's various websites and the 
difference in tutorial and sample code quality was overwhelmingly in 
favor of PHP back then. Since then, perl.apache.org has been revamped, 
but it takes a long time to change people's perceptions.

Sadly, (or perhaps justifiably so), documentation can make all the 
difference in the success or failure of an open source project. Not the 
code quality or architecture of the project.

3) In any case, to get close to the speed of PHP, you need mod_perl 
(which is arguably faster than PHP), but to get close to the 
user-friendliness/learning curve of PHP, you have to stay in the world 
of CGI. Although this is my opinion, I believe this, at least, to be 
arguably true.

4) It's not just that something has a big corporation behind it that can 
make it a success. It's also your "partners" and how big they are. ISPs, 
for example, would be the "best friend" for any technology to have.

Unfortunately for Perl, I would not be surprised if the ISPs have had a 
hand in pushing PHP's success. Given that PHP will consume less 
resources than launching CGI shells but allow any beginner to do so (as 
opposed to mod_perl), what ISP wouldn't want to encourage their users to 
use PHP instead of Perl/CGI? If they can handle 20 users on a box using 
Perl/CGI but 100 users on the same box if those users switched to PHP, 
it obviously helps the ISPs bottomline to have people use PHP. See my 
comment in #1... sadly, there is no way to easily enable mod_perl by 
default.

The list of ISPs supporting mod_perl has been growing, but it is still 
quite sparse..

5) I have done some PHP coding and found it extraordinarily easy to pick 
up. I wouldn't move to it however because I find that for my purposes 
CPAN is actually a big bonus. eg I am recently programming in 
bioinformatics field again after a hiatus in the financial world for 5 
years...how many tools exist to integrate with bioinformatics tools in 
PHP? Maybe a few, but certainly compared to Java and PHP, Perl has 
libraries for that domain beat hands down. Even if the modules are not 
in CPAN, many websites have various bits of Perl libraries for accessing 
their bioinformatics tools. And so just continuing to use Perl makes a 
lot of sense. For me. :)

I think a lot of other people who advocate Perl in "one word: CPAN" 
probably feel the same as me though. And that is heartening. :)

Thanks,
  Gunther
Octavian Rasnita wrote:

Of course I will remain subscribed and I am not gonna start learning PHP
immediately.
I am thinking to learn it because in my country there are only 2 books for
learning perl in my native language and even though I don't need them, there
are very few perl programmers and almost no jobs for perl developers.
There are even some programmers that just heard about perl but they don't
even know too well what it is, and they are good programmers in their
languages.
My problem is that I am used to work under Windows where no compiler is
installed by default and where some CPAN modules don't even compile under
this OS, and I cannot just jump and use Linux because Linux is not an
operating system too accessible for the blind, and I am totally blind.
Unfortunately I cannot try to solve this problem and start creating an
accessible version of Linux then creating perl programs under this OS.
Perl is great because OF CPAN also, but there are very many modules that
require Linux, some of them don't even tell this but the modules don't even
want to compile under this OS.
I am not trying to convince somebody that PHP or Java is better than perl,
but I am just trying to see what makes those programming languages so... "en
vogue".
For example a programmer in Java can create not only java servlets or java
server pages, but they can also create java applets and des

Re: PHP vs Perl

[Octavian Rasnita]

Of course I will remain subscribed and I am not gonna start learning PHP
immediately.
I am thinking to learn it because in my country there are only 2 books for
learning perl in my native language and even though I don't need them, there
are very few perl programmers and almost no jobs for perl developers.
There are even some programmers that just heard about perl but they don't
even know too well what it is, and they are good programmers in their
languages.

My problem is that I am used to work under Windows where no compiler is
installed by default and where some CPAN modules don't even compile under
this OS, and I cannot just jump and use Linux because Linux is not an
operating system too accessible for the blind, and I am totally blind.
Unfortunately I cannot try to solve this problem and start creating an
accessible version of Linux then creating perl programs under this OS.

Perl is great because OF CPAN also, but there are very many modules that
require Linux, some of them don't even tell this but the modules don't even
want to compile under this OS.

I am not trying to convince somebody that PHP or Java is better than perl,
but I am just trying to see what makes those programming languages so... "en
vogue".

For example a programmer in Java can create not only java servlets or java
server pages, but they can also create java applets and desktop programs
with a graphical interface while this is not possible with perl.
Internet Explorer, the most used browser can display java applets, but it
doesn't support perl scripts and those perl scripts cannot create a
graphical interface in the browser.
perl can create descktop programs with a graphical interface using the Tk
modules, but those modules are not accessible at all for the blind. They use
some strange classes that print the form like a picture on the screen while
Java programs can be made accessible with Java Access Bridge.

Well, see, these are perl problems, but perl doesn't have a company like Sun
Microsystems to fight to solve them, and it doesn't have so many advertisers
either.
For example, after installing Apache under Windows, by default PHP is set to
be accepted after instalation, but perl is not set and we need to add the
"AddHandler" lines in the httpd.conf file in order to make it work.

It is very clear that Apache is promoting PHP and there are not very many
companies that promote perl.
I've started to find (very strange) web hosting providers in my country that
offer PHP support and space for free and some of them unlimited traffic, but
they don't offer perl support at all.

I am not sure that PHP is used more than perl now, but after 5 years... it
will be used more than perl for sure.

Which could be the solutions?
- To have some Tk classes that are accessible for people with dissabilities.
- To be able to have the programs compiled as binaries (.exe under Windows)
without needing to embed the perl interpreter in the code like with perlapp,
or to have a kind of runtime environment - the perl interpreter installed
separately, but without any other unneeded modules.
- to have a very good development environment for programmers (I don't need
it, but new programmers in this language is searching for such a thing) and
it doesn't exist.
(I've tried comodo of ActiveState, but it is not accessible for the blind
like other programming languages environments)
- To have precompiled modules for Windows and for other operating systems
for much more packages than ActiveState has now.
- To have a set of kind of standard modules for creating, editing and
reading more file types that are precompiled and which can be installed
easier and a set of modules for working on the web, comunicating with more
merchant accounts,  shopping carts...
- to promote packages that contain perl, Apache, MySQL and possibly other
tools for programmers, because most programmers that test their programs
locally need them.
...

Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]

- Original Message -
From: "Todd W." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 28, 2003 5:21 AM
Subject: Re: PHP vs Perl



"Octavian Rasnita" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I think the reason why PHP is used more and more much than Perl is that
for
> CGI related programs it is much simpler to use than perl.

Octavian , you haven't _proved_ that PHP is used more than perl.

> For example it has a set of libraries for the most used functions in a CGI
> program, for example SSL support, a module for reading and creating PDF
> files, modules for accessing some payments operators for shopping carts,
> etc.
> Those modules can be created in perl, but even if some of those modules
> exists for perl, they don't work  very well. I've tried to use the modules
&g

Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[Todd W.]

"Camilo Gonzalez" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Okay, this is a beginner's list. What the hell is MVC? How do you hash
> an algorithm?
>

As far as the hash algorithm, this concerns perl hashes.

As you ( probably ) know, perl has a built in data structure called a hash.
What this data structure enables, more or less, is the ability to index
arbitrary values with arbitrary strings.

A hash has certain defined properties. For instance, hashes cannot have
duplicate keys, and regardless of hash size ( 1 element or 1 billion
elements ) it ( theoretically ) takes ( about ) the same amount of time to
map a key to a value.

The people that wrote the C code to implement perl hashes did not just sit
down and come up with their own ideas from scratch on how to do it. They
used several mathematical theories used in computer science, one being
called "hashing."

As always, perl.com fills in the gory details:

http://www.perl.com/pub/a/2002/10/01/hashes.html

Todd W



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[Todd W.]

"Drieux" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>
> Todd either Paused for more MountainDew or had a Moment:
> [..]
> > Those last two paragraphs were total rant,  and I probably
> > have no idea what I'm talking about, but they are getting posted
> > anyway ;0)
> [..]
>
> I would like be so totally opposed to your
> position if it were not for most of the dark horror
> of where I so totally agree with you
>
> But First off - COOL RANT!

I was hoping that _some_ day I could string a few sentences together as well
as you do =0) Unfortunately, I dont think I have accomplished it yet!!!


> p0: let us not confused science, technology and VOODOO.
> Computer Science is wonderful for providing a theoretical
> intellectual underpinning to hashing algorithms, while
> a specific instance of that as a technology of course
> is perl's 'hash' data structure, the actual 'coolness'
> of course lies in using it in strange and arcane ways
> that border on Voodoo.
>
> bless this ref...

I agree, as long as you agree that the more one understands the CS theory,
the less voodoo there is in the implementation.

>
>
> p2: I am very nervous that folks are noticing that
> at present PHP is not supportive of MVC as a design
> pattern - and that may be a limiting factor - but as
> you have also noted, given the gaggelation of globulated
> together 'stuff' - eg: ASP+HTML+SQL - this means that
> there are still great employment opportunities refactoring
> that stuff into maintainable code. So we should support
> the spread of PHP without MVC as a basis for more work
> refactoring the code???
>
> return unless defined( $ref );

I think that most languages are supportive of MVC as a design pattern, but
each language's advocates and tutorial designers are not. All intro
tutorials are rightfully simple and stratightforward example usages of a
technology. But as we have been discussing, most developers, it seems, take
this as the end-all be-all of app development technology, declare themselves
proficient, and consider the tutorial reason enough to add to the "expert"
column on one's resume. This leads right to the next comment:

>
> p4: given that hacking in perl does not require MVC as
> a design pattern, but one can learn the hard way to support it
>

We have AxKit, but I wouldnt like to call it the canonical perl MVC pattern.
Most familiar with it probably would though. ASP.NET has MVC with its "code
behind" concept.

Im not aware of any other MVC based platforms right off.

Todd W.



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PHP vs Perl

[Todd W.]

"Octavian Rasnita" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I think the reason why PHP is used more and more much than Perl is that
for
> CGI related programs it is much simpler to use than perl.

Octavian , you haven't _proved_ that PHP is used more than perl.

> For example it has a set of libraries for the most used functions in a CGI
> program, for example SSL support, a module for reading and creating PDF
> files, modules for accessing some payments operators for shopping carts,
> etc.
> Those modules can be created in perl, but even if some of those modules
> exists for perl, they don't work  very well. I've tried to use the modules
> for creating a PDF document under Windows, but with no success.
> It is pretty hard to install some of the perl modules under Windows
because
> most of them need to be compiled, need a compiler to be installed, etc.
> With PHP it is much simpler to work and I can see this even though I don't
> know PHP at all yet.

Perl does all those things you mention very well. Please don't take offense
here, this is your thread. But, you say that you have tried to use perl
implementations of web technology, and you claim in this post that, "they
don't work very well." Then you say that PHP has simpler implementations,
yet you haven't attempted to use any of them.

I am willing to bet, Octavian, that you are going to have just as difficult
a time trying to do those things in PHP as you are having in perl. This is
because, Octavian, your rationale for switching to PHP.

It appears the purpose of your OP is that you have a need for a tool or
tools written in perl that need compiled. Because you are unfamiliar with
compiling code, you solution is to, rather than learn to compile code,
switch to a different technology.

I feel obligated to warn you, Octavian, that this choice will doom you to
repeated failure, because you have chosen to circumvent the problem rather
than solve it.

A true software developer, Octavian, will be able to implement a solution in
any modern computer language. Because a true software developer has been
versed in concepts like data modeling and "manual" activities like compiling
C source code, this developer will use proven methodology to design a
solution for a customer or idea. Only after the solution has been designed
will the developer begin to contemplate secondary requirements like what
language to implement the solution in.

So, Octavian, you may very well learn to do the simple things you have been
doing with perl in PHP, and they may very well seem easier to you. But, as
soon as you run into doing something complicated, you will be right back
where you started. You are going to have to do something you cant figure
out, and be posting to a newsgroup that the tool you are trying to use
"don't work very well".

I am NOT flaming you, Octavian. I have read many of your posts and you have
helped alot of people on this list and we are grateful. Even if you do
change your base technology, we all hope that you stay subscribed to the
list and continue to contribute.

Todd W.




-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PHP vs Perl

[drieux]

On Sunday, Jul 27, 2003, at 13:25 US/Pacific, Octavian Rasnita wrote:
[..]
It is not very easy to install support for SSL, or the library
for creating images for perl, while for PHP is much easier.
[..]

let's think about this for a moment - do you know which
SSL layer you are working with in PHP and do you understand
the risks in the various versions of SSL?
Or is the hope that the PHP folks have installed the
correct version?
At which point we can of course get into the discussion
of who is 'responsible' for monitoring the 'security alert
bullitins' with regards to 'vagaries' in this or that
implementation of SSL...
at which point we arrive at the question

and a cgi piece of code should know that
it was called over an SSL connection by
which non-spoofable mechanism?
Or is this the part of the process where we shift
to the question of encrypted VPN client connection
mechanism as a more interesting model for dealing
with what information should be 'more tightly
guarded' from prying eyes?
Or were we planning to deal with 'information
encryption' as a part of the problem here?
ciao
drieux
---

You can have my Compiler
when you rip it from my Cold Dead Hands


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PHP vs Perl

[Octavian Rasnita]

Of course you're almost right, but exactly this is a problem. A language
which I need to fight a lot with in order to find the right syntax for doing
something is not a very clear and easy to use programming language.
I like more the perl way than needing to learn very many functions names,
like when working with PHP or Visual Basic, but I like that PHP can be
installed as a package with the most used libraries, I also like that there
are some prebuild packages that contain Apache, MySQL and PHP configured in
such a way that they all work very nice.
There is no such a thing for Perl.
It is not very easy to install support for SSL, or the library  for creating
images for perl, while for PHP is much easier.
...

Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]

- Original Message -
From: "Scot Robnett" <[EMAIL PROTECTED]>
To: "Octavian Rasnita" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, July 27, 2003 8:35 PM
Subject: RE: PHP vs Perl


I think there are a couple of myths that need to be cleared up from that
post.

First, the idea that PDF manipulation and secure payment modules "don't work
very well" in Perl. If one has had difficulty in making the modules work for
them, it does not necessarily mean that the module is at fault - in some
cases it might be, but typically I've found that when a module isn't working
for me, I've usually missed something.

Second, the idea that most of the new work can be found in PHP and ASP is
not necessarily the case. The tech industry has taken a hit over the past
few years, and if you're looking at the job boards like Monster, maybe most
of what you *see* is slanted toward Microsoft technology. PHP and ASP are
pushed at corporations because somebody at a high level in the chain has
been told these are the widgets they should use. Trust me, I worked for one
of the major telecom players for 6 years, and I've seen how the buzzwords
work themselves into the hiring process.

However, in my business (I deal with small to medium-sized companies),
they're not concerned about what technology I use as long as it works. So
far, the language that makes most of my projects work is Perl.



-Original Message-
From: Octavian Rasnita [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 1:38 PM
To: [EMAIL PROTECTED]
Subject: Re: PHP vs Perl


I think the reason why PHP is used more and more much than Perl is that for
CGI related programs it is much simpler to use than perl.
For example it has a set of libraries for the most used functions in a CGI
program, for example SSL support, a module for reading and creating PDF
files, modules for accessing some payments operators for shopping carts,
etc.
Those modules can be created in perl, but even if some of those modules
exists for perl, they don't work  very well. I've tried to use the modules
for creating a PDF document under Windows, but with no success.
It is pretty hard to install some of the perl modules under Windows because
most of them need to be compiled, need a compiler to be installed, etc.

With PHP it is much simpler to work and I can see this even though I don't
know PHP at all yet.

The motivation for new perl learners is not very big because most of the
jobs can be found in PHP/ASP and only after that in perl/Cold Fusion.

I hope Perl 6 will have much more standard modules and the modules from CPAN
will be able to be installed without compiling them with a local compiler.
We should keep in mind that even if the most web servers are running under
Unix/Linux, most computer users and possibly web developers are working
under Windows and the CPAN modules should be all compatible with Windows
also,  and not only with Linux.

Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]

- Original Message -
From: "Todd W." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 24, 2003 11:26 PM
Subject: Re: PHP vs Perl



<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> > 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..
>

I was thinking the same thing when I read that. Swap the first occurence of
'PHP' with the first occurence of 'Perl' in the paragraph and you have a
perfectly formulated reason of why you should use perl over PHP !!??!!

It says, 

Re: PHP vs Perl

[drieux]

On Sunday, Jul 27, 2003, at 12:57 US/Pacific, Jon Hogue wrote:
[..]
With CGI::FormBuilder, I couldn't imagine CGI being any easier...
cf:

cf:

Oh SURE, now you advocate that

for those who read comments in pod, please note:

# Need some magical JavaScript crap to figure out the 
type of value
# God the DOM sucks so much ass I can't believe the 
value element
# changes based on the type of field!!
#
# Note we have to use form.elements['name'] instead of 
just form.name
# as the JAPH using this module may have defined fields 
like "u.type"
#
# Finally, we expand our error message above, way up 
here, so that
# we can simply integrate the custom message with the 
predefined text

So if you are 'beginning' in the land of Perl v. PHP
and are not sure how/why/where to opt which set of
horrors with stuff like JavaScript - let's be honest
happy campers, that comment bar says more than we
all like to admit in polite society about the fact
that there are 'vagaries' that exist in the 3 DOM's,
and the 'featureFullNeff' of how 'JavaScript' has
devolved to begin with
ciao
drieux
---

ps: some seriously SLICK stuff there

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PHP vs Perl

[Jon Hogue]

With CGI::FormBuilder, I couldn't imagine CGI being any easier...

For most CGI programs, Formbuilder can increase your speed of development 
and clarity of code by 10 fold.

Plus, Perl's got Larry Wall. And training on cruise ships in Hawaii. 'nuff 
said. :-)

At 07:55 PM 7/27/2003 +0300, Octavian Rasnita wrote:
This is the reason I've began to learn perl and not PHP, but for CGI
programs I found that PHP might be easier.
I know that PHP is much more limited even for CGI programs than perl, but
for simple tasks it is much better.
And... most CGI programs are not extremly complicated.
Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]
- Original Message -
From: "zentara" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 27, 2003 7:43 PM
Subject: Re: PHP vs Perl
On Wed, 26 Feb 2003 21:38:08 +0200, [EMAIL PROTECTED] (Octavian Rasnita)
wrote:
>I think the reason why PHP is used more and more much than Perl is that for
>CGI related programs it is much simpler to use than perl.
I don't mess around with php, but I do follow the discussions of it's
merits vs. perl on http://perlmonks.org.
I've been able to synthesize this from all the discussions:

PHP will give you the same performance benefits as using mod-perl.

PHP's drawback is that you are learning a language that can only be
used for web programming.
So well written mod-perl is comparable to PHP. I think the allure of PHP
is that it is probably easier for a beginner to learn, but it is a
dead-end, because you can't use it outside of web programming.
And as most perl programmers know, web programming is only a tiny
part of the usefulness of perl.sysadmin scripts, text processing,
task automation,etc.




--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PHP vs Perl

[drieux]

On Sunday, Jul 27, 2003, at 09:55 US/Pacific, Octavian Rasnita wrote:
[..]
I know that PHP is much more limited even for CGI programs than perl,
but for simple tasks it is much better.
And... most CGI programs are not extremly complicated.
[..]

That really is the crux of the problem.

How 'complex' IS the over all project really
going to become
While 'many' cgi programs themselves may
not be 'extremly complicated' - especially
when they start out - the problem is keeping
them in that 'small, simple, easy' set of tasks.
At which point there is both a technology set
of questions, and dare i propose it, an ethical
set of questions. Do we as professionals have an
obligation to warn our clients that while they may
be able to solve 'foo' quickly with some PHP/ASP?
that we can, if we can, see that their core project will
grow beyond that limited scope...
Or should we bill the contract once to whip up the
simpler PHP/ASP/WhatEver - and then be ready in the
wings to re-bill them to refactor the project into
something that will handle their more, uh, complex
and actual problems.
A position I am willing to take with regards to Perl as well.

If perl is not a good fit for the type of project, then clearly
one should not merely adopt the cavalier attitude that perl-cgi
and/or mod_perl is the Majik...
{ while I love the fact that 'perl is everywhere' - the simpler
solution for 'init scripting' on most unix boxes remains the
simple light, and DUMB /bin/sh script... So if the 'server side'
will need to have a special daemon process that is going to be
run behind the web-server, then plan to deliver the init scripting
that will start/stop it... }
Most of us 'reach for our perl' - if for no other reason, than
we KNOW the pain of putting it together as an LRL parser in
say Lex and Yacc, when all we need is merely some reasonably
painful and annoying Regular Expression Parser - but one that
will be a whole lot simpler to maintain, and far more portable
than the Lex and Yacc... { yes boys and girls, if we want to
have SERIOUS flameFesting, then, uh nope, do not want to... }
ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PHP vs Perl

[Octavian Rasnita]

This is the reason I've began to learn perl and not PHP, but for CGI
programs I found that PHP might be easier.
I know that PHP is much more limited even for CGI programs than perl, but
for simple tasks it is much better.
And... most CGI programs are not extremly complicated.

Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]

- Original Message -
From: "zentara" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 27, 2003 7:43 PM
Subject: Re: PHP vs Perl


On Wed, 26 Feb 2003 21:38:08 +0200, [EMAIL PROTECTED] (Octavian Rasnita)
wrote:

>I think the reason why PHP is used more and more much than Perl is that for
>CGI related programs it is much simpler to use than perl.

I don't mess around with php, but I do follow the discussions of it's
merits vs. perl on http://perlmonks.org.

I've been able to synthesize this from all the discussions:

PHP will give you the same performance benefits as using mod-perl.

PHP's drawback is that you are learning a language that can only be
used for web programming.

So well written mod-perl is comparable to PHP. I think the allure of PHP
is that it is probably easier for a beginner to learn, but it is a
dead-end, because you can't use it outside of web programming.
And as most perl programmers know, web programming is only a tiny
part of the usefulness of perl.sysadmin scripts, text processing,
task automation,etc.





--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: PHP vs Perl

[Scot Robnett]

I think there are a couple of myths that need to be cleared up from that post. 

First, the idea that PDF manipulation and secure payment modules "don't work very 
well" in Perl. If one has had difficulty in making the modules work for them, it does 
not necessarily mean that the module is at fault - in some cases it might be, but 
typically I've found that when a module isn't working for me, I've usually missed 
something. 

Second, the idea that most of the new work can be found in PHP and ASP is not 
necessarily the case. The tech industry has taken a hit over the past few years, and 
if you're looking at the job boards like Monster, maybe most of what you *see* is 
slanted toward Microsoft technology. PHP and ASP are pushed at corporations because 
somebody at a high level in the chain has been told these are the widgets they should 
use. Trust me, I worked for one of the major telecom players for 6 years, and I've 
seen how the buzzwords work themselves into the hiring process. 

However, in my business (I deal with small to medium-sized companies), they're not 
concerned about what technology I use as long as it works. So far, the language that 
makes most of my projects work is Perl.



-Original Message-
From: Octavian Rasnita [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 1:38 PM
To: [EMAIL PROTECTED]
Subject: Re: PHP vs Perl


I think the reason why PHP is used more and more much than Perl is that for
CGI related programs it is much simpler to use than perl.
For example it has a set of libraries for the most used functions in a CGI
program, for example SSL support, a module for reading and creating PDF
files, modules for accessing some payments operators for shopping carts,
etc.
Those modules can be created in perl, but even if some of those modules
exists for perl, they don't work  very well. I've tried to use the modules
for creating a PDF document under Windows, but with no success.
It is pretty hard to install some of the perl modules under Windows because
most of them need to be compiled, need a compiler to be installed, etc.

With PHP it is much simpler to work and I can see this even though I don't
know PHP at all yet.

The motivation for new perl learners is not very big because most of the
jobs can be found in PHP/ASP and only after that in perl/Cold Fusion.

I hope Perl 6 will have much more standard modules and the modules from CPAN
will be able to be installed without compiling them with a local compiler.
We should keep in mind that even if the most web servers are running under
Unix/Linux, most computer users and possibly web developers are working
under Windows and the CPAN modules should be all compatible with Windows
also,  and not only with Linux.

Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]

- Original Message -
From: "Todd W." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 24, 2003 11:26 PM
Subject: Re: PHP vs Perl



<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> > 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..
>

I was thinking the same thing when I read that. Swap the first occurence of
'PHP' with the first occurence of 'Perl' in the paragraph and you have a
perfectly formulated reason of why you should use perl over PHP !!??!!

It says, "PHP has a less confusing and stricter format without losing
flexibility." Which is fine for printing environment variables to a browser,
but the second you try to do something like implement a MVC pattern ( which
is the way one is supposed to develop distrbuted applications, but is
inherently anti-PHP ) the language proper becomes as flexible as a 12 inch
piece of 2x4, so you're left with nothing but a prop or a VERY crude hammer
=0).

I went to a consuting firm, and they had this app with 50 different files of
ASP+HTML+SQL, all mixed together, and they said they wanted a pocket IE
interface to the app. I said okay, the first thing we do here is right
click -> delete on the parent folder. They said no. I asked them how they
wanted me to do it, and they wanted a new folder with the same files except
for this ASP outputs the PIE interface. I'll pass.

But you know, to each his own. During the opening talk at YAPC::NA this year
Conway had slide that contained a list of 10 or so bullet

Re: PHP vs Perl

[zentara]

On Wed, 26 Feb 2003 21:38:08 +0200, [EMAIL PROTECTED] (Octavian Rasnita)
wrote:

>I think the reason why PHP is used more and more much than Perl is that for
>CGI related programs it is much simpler to use than perl.

I don't mess around with php, but I do follow the discussions of it's
merits vs. perl on http://perlmonks.org. 

I've been able to synthesize this from all the discussions:

PHP will give you the same performance benefits as using mod-perl.

PHP's drawback is that you are learning a language that can only be
used for web programming.

So well written mod-perl is comparable to PHP. I think the allure of PHP
is that it is probably easier for a beginner to learn, but it is a
dead-end, because you can't use it outside of web programming.
And as most perl programmers know, web programming is only a tiny
part of the usefulness of perl.sysadmin scripts, text processing,
task automation,etc.





-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PHP vs Perl

[drieux]

volks,

p0: let's chill a bit and think about the 'well reasoned'
portions of the kvetch so far.
{ the alternative is the I WILL let my Pixies Out
and that will not be a pretty sight... }
Prefatory Kvetch:

I think one of the ultimate problems is that unlike the
benchmarking that we can do inside of Perl to at least
put some 'technical numbers' around the cost of doing
'foo over bar' - the assertion
	'foo is simpler than bar'

is less easy to demonstrate imperically. All of which
gets compounded by the 'time to market', 'head count costs',
'refactoring costs' So for a field that is alledgedly
about 'computational arts' - so much of it has less to
do with the computable, than with the art
p1: the economic problem -

The motivation for new perl learners is not very big because most of  
the
jobs can be found in PHP/ASP and only after that in perl/Cold Fusion.
Unfortunately you make a really scary argument here.
Why learn Perl if it really is tomorrow's Cobol.
Amongst the questions then is whether the 'available jobs'
are being driven by 'weird market hopes'. In this case that
majikally the 'problem' that they want solved will be solvable
simply with 'just some PHP/ASP stuff' - hence that they can
pick up cheaply that 'will code HTML for food' person...
When what will ultimately happen is that they will need to
deal with the actual 'software development cycle' and the
consequences that they did not start from a design pattern
of any type at all
If we should have learned anything from the e-Biz/Internet Craze
then it clearly would be the difference between being able to
type text into a text editor and being able to DO software
development based upon 'best practices' in the art.
I am MORE than willing to concede right here and now that there
are people with CV's that say that they were the VP of engineering,
the Chief Architect, , who
can 'legitimately' say that was their actual title at dot.bomb.com
and may have been hired by people who just do not have a technical
clue about what those 'roles' are - nor how to tell 'capability'
from 'good marketting spin'.
5) From my time spent in the job market I would say it is pretty well
divided among all of the languages, especially since most postings read
something like "6 years of experience in Perl, CGI, ASP, PHP, Oracle,
COBOL"  (love that last one) which is a very poor indicator of the
actual market...
So a part of the 'professional' problem here is how to differenciate
the 'pros' from those who are still learning... On both sides of
the hiring table...
I'm almost willing to say that we may be doing people harm
by trying to sell perl as a simple easy thingie poo. At least
as easy as  - since software stuff tends to
get complex real quick, and no amount of Management Hopes that
'a little scripting' will majikally rescue their delivery date.
cf:


p2: the Keep Perl Alive Position:
[..]
If we say that perl don't have any problem it will be used
less and less without having any problem. I think that we
should point out which are its problems because maybe they can be  
solved.

[..]

Hopefully we all agree on this! as it is clearly just the right thing.

Hopefully we are actually going at 'the real issues' about what
really needs to be added/updated to Perl.
Just an odd thought here - have you been following the P5EE discussions?

p3: The windows/*nix problem:

I hope Perl 6 will have much more standard modules and the modules
from CPAN will be able to be installed without compiling them with
a local compiler.
This is a reasonable enough argument, if one is looking
at the 'perl only' model - but I think a part of the
advantage of 'needing a local compiler' is that they are
such lovely pieces of technology. There is the advantage
that gcc 3.3 comes in more flavors than I would prefer to
think about. But there are also RPM - red hat package
managers - and ActiveState is doing a very good job, or
so I am told for those who 'just want the binaries'.
We should keep in mind that even if the most web servers are
running under Unix/Linux, most computer users and possibly
web developers are working under Windows and the CPAN modules
should be all compatible with Windows also, and not only with Linux.
This is a 'strange' position, and forgive me, it is hard for me
to imagine that I would be developing for target platform 
to which I did not have something that was at least analogous.
{ note - yes, I do have code out there that will run on an
OS that is not in the crib, but that's life, in that case it
was a 'one off' of stuff we do have in the crib. Ok, I take
that back, I have code for systems that do not run anymore,
unless someone out there wants some Cray-2 code But back
then I did have access to it...}
I'm trying to understand why one would be a professional
software developer who has not started the process of
building out their own 'lab' to work with. This of course
goes back to

Re: PHP vs Perl

[Octavian Rasnita]

I don't say that mine is bigger than yours because perl is the only
programming language I know and I found out that I also need to know a
little C if I want to compile some perl modules that give a lot of errors.
I don't know PHP at all, but I found out that I could create the same thing
with PHP without needing me to know other programming languages.

In fact I also want to know why PHP is used more than Perl and this is
obviously.
I see less and less CGI files ending with .cgi or with .pl or /cgi-bin/
directories in the path of the URLS, but more and more I can see .php and
.jsp.

If we say that perl don't have any problem it will be used less and less
without having any problem.
I think that we should point out which are its problems because maybe they
can be solved.

Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]

- Original Message -
From: "Wiggins d'Anconia" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 27, 2003 1:05 AM
Subject: Re: PHP vs Perl


Octavian Rasnita wrote:

> I think the reason why PHP is used more and more much than Perl is that
for
> CGI related programs it is much simpler to use than perl.
> For example it has a set of libraries for the most used functions in a CGI
> program, for example SSL support, a module for reading and creating PDF
> files, modules for accessing some payments operators for shopping carts,
> etc.
> Those modules can be created in perl, but even if some of those modules
> exists for perl, they don't work  very well. I've tried to use the modules
> for creating a PDF document under Windows, but with no success.
> It is pretty hard to install some of the perl modules under Windows
because
> most of them need to be compiled, need a compiler to be installed, etc.
>
> With PHP it is much simpler to work and I can see this even though I don't
> know PHP at all yet.
>
> The motivation for new perl learners is not very big because most of the
> jobs can be found in PHP/ASP and only after that in perl/Cold Fusion.
>
> I hope Perl 6 will have much more standard modules and the modules from
CPAN
> will be able to be installed without compiling them with a local compiler.
> We should keep in mind that even if the most web servers are running under
> Unix/Linux, most computer users and possibly web developers are working
> under Windows and the CPAN modules should be all compatible with Windows
> also,  and not only with Linux.
>

This is the same kind of canned response that is the reason why this is
a flame war topic and was met with such jest immediately after being
asked.

1) Still not possible to prove that PHP is used more than Perl, which
also makes it impossible to prove it isn't

2) All of the modules you stated exist for PHP, exist for Perl, many of
them probably before those for PHP were developed. CPAN is the envy of
all languages, ask a Java developer familar with Perl sometime about how
they feel about CPAN...

3) What modules have you used that didn't work very well?  Ignorance
with respect to a module's interface does not prove poor performance.
Most modules that I have encountered have all worked as they claimed and
solved the goals' that they were designed for.

4) ActiveState has a very good list of modules available in a binary
format and that list is growing continuously, and most modules (at least
those that would be used on the web) are available from ActiveState, or
either without a compiler (though make is needed) or will compile under
windows with the proper free utilities. Laziness with regards to
installing modules doesn't indicate they don't or won't work.

5) From my time spent in the job market I would say it is pretty well
divided among all of the languages, especially since most postings read
something like "6 years of experience in Perl, CGI, ASP, PHP, Oracle,
COBOL"  (love that last one) which is a very poor indicator of the
actual market...

6) I feel sorry for the development house (and their clients) that
develops their site on a different system than it will be served (and I
don't mean a developer sitting at a Windoze machine ssh'd into the
server since that can't count because in that case they don't need the
modules locally).  Which means that if they are serving on Windows they
know what is available and are more likely able to get something to work
(I mean they are developers they ought to have a compiler available on
their own platform and know how to use it).  On Linux/*nix of course
this is mostly moot... (and there is 60+% of us on that platform)...

7) Let's not even mention coldfusion...

Now we were having a very nice (albeit weird) discussion about MVC and
pixies, let's not turn this into the typical mine is bigger than your's
discussion

http://danconia.org


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PHP vs Perl

[Wiggins d'Anconia]

Octavian Rasnita wrote:

I think the reason why PHP is used more and more much than Perl is that for
CGI related programs it is much simpler to use than perl.
For example it has a set of libraries for the most used functions in a CGI
program, for example SSL support, a module for reading and creating PDF
files, modules for accessing some payments operators for shopping carts,
etc.
Those modules can be created in perl, but even if some of those modules
exists for perl, they don't work  very well. I've tried to use the modules
for creating a PDF document under Windows, but with no success.
It is pretty hard to install some of the perl modules under Windows because
most of them need to be compiled, need a compiler to be installed, etc.
With PHP it is much simpler to work and I can see this even though I don't
know PHP at all yet.
The motivation for new perl learners is not very big because most of the
jobs can be found in PHP/ASP and only after that in perl/Cold Fusion.
I hope Perl 6 will have much more standard modules and the modules from CPAN
will be able to be installed without compiling them with a local compiler.
We should keep in mind that even if the most web servers are running under
Unix/Linux, most computer users and possibly web developers are working
under Windows and the CPAN modules should be all compatible with Windows
also,  and not only with Linux.
This is the same kind of canned response that is the reason why this is 
a flame war topic and was met with such jest immediately after being 
asked.

1) Still not possible to prove that PHP is used more than Perl, which 
also makes it impossible to prove it isn't

2) All of the modules you stated exist for PHP, exist for Perl, many of 
them probably before those for PHP were developed. CPAN is the envy of 
all languages, ask a Java developer familar with Perl sometime about how 
they feel about CPAN...

3) What modules have you used that didn't work very well?  Ignorance 
with respect to a module's interface does not prove poor performance. 
Most modules that I have encountered have all worked as they claimed and 
solved the goals' that they were designed for.

4) ActiveState has a very good list of modules available in a binary 
format and that list is growing continuously, and most modules (at least 
those that would be used on the web) are available from ActiveState, or 
either without a compiler (though make is needed) or will compile under 
windows with the proper free utilities. Laziness with regards to 
installing modules doesn't indicate they don't or won't work.

5) From my time spent in the job market I would say it is pretty well 
divided among all of the languages, especially since most postings read 
something like "6 years of experience in Perl, CGI, ASP, PHP, Oracle, 
COBOL"  (love that last one) which is a very poor indicator of the 
actual market...

6) I feel sorry for the development house (and their clients) that 
develops their site on a different system than it will be served (and I 
don't mean a developer sitting at a Windoze machine ssh'd into the 
server since that can't count because in that case they don't need the 
modules locally).  Which means that if they are serving on Windows they 
know what is available and are more likely able to get something to work 
(I mean they are developers they ought to have a compiler available on 
their own platform and know how to use it).  On Linux/*nix of course 
this is mostly moot... (and there is 60+% of us on that platform)...

7) Let's not even mention coldfusion...

Now we were having a very nice (albeit weird) discussion about MVC and 
pixies, let's not turn this into the typical mine is bigger than your's 
discussion

http://danconia.org

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PHP vs Perl

[Octavian Rasnita]

I think the reason why PHP is used more and more much than Perl is that for
CGI related programs it is much simpler to use than perl.
For example it has a set of libraries for the most used functions in a CGI
program, for example SSL support, a module for reading and creating PDF
files, modules for accessing some payments operators for shopping carts,
etc.
Those modules can be created in perl, but even if some of those modules
exists for perl, they don't work  very well. I've tried to use the modules
for creating a PDF document under Windows, but with no success.
It is pretty hard to install some of the perl modules under Windows because
most of them need to be compiled, need a compiler to be installed, etc.

With PHP it is much simpler to work and I can see this even though I don't
know PHP at all yet.

The motivation for new perl learners is not very big because most of the
jobs can be found in PHP/ASP and only after that in perl/Cold Fusion.

I hope Perl 6 will have much more standard modules and the modules from CPAN
will be able to be installed without compiling them with a local compiler.
We should keep in mind that even if the most web servers are running under
Unix/Linux, most computer users and possibly web developers are working
under Windows and the CPAN modules should be all compatible with Windows
also,  and not only with Linux.

Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]

- Original Message -
From: "Todd W." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 24, 2003 11:26 PM
Subject: Re: PHP vs Perl



<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> > 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..
>

I was thinking the same thing when I read that. Swap the first occurence of
'PHP' with the first occurence of 'Perl' in the paragraph and you have a
perfectly formulated reason of why you should use perl over PHP !!??!!

It says, "PHP has a less confusing and stricter format without losing
flexibility." Which is fine for printing environment variables to a browser,
but the second you try to do something like implement a MVC pattern ( which
is the way one is supposed to develop distrbuted applications, but is
inherently anti-PHP ) the language proper becomes as flexible as a 12 inch
piece of 2x4, so you're left with nothing but a prop or a VERY crude hammer
=0).

I went to a consuting firm, and they had this app with 50 different files of
ASP+HTML+SQL, all mixed together, and they said they wanted a pocket IE
interface to the app. I said okay, the first thing we do here is right
click -> delete on the parent folder. They said no. I asked them how they
wanted me to do it, and they wanted a new folder with the same files except
for this ASP outputs the PIE interface. I'll pass.

But you know, to each his own. During the opening talk at YAPC::NA this year
Conway had slide that contained a list of 10 or so bullets explaining why
perl 5 OO is good. And on the very next slide used the exact same 10 bullet
list to illustrate why perl 5 OO is bad!?! I think this boils down to Wall's
philosophy of post-modernism. I'm no sociologist, and what I've learned of
post-modernisim has been from Wall, but I understand, post-modernism as
"this AND that" as opposed to "this OR that".

And I agree with him. perl 5 OO boils down to a builtin ( namely, bless() )
that tells a reference that all subroutines in the package named in the
second argument are its methods. Now one can write some pretty cool code
with that, using a fraction of the disk space that the C# implementation
would require.

But try translating that to a monkey coder, or that high schooler you
mentioned that is happy getting paid in soda. Why become a real computer
scientist and learn about polymorphisim or hashing algorithms when you can
crack another mountain dew and pound on a keyboard for awhile. So what if
the development time is 6 months over schedule. Just add another semester of
VC++ 6 and, voila, a shiny piece of paper declaring the worlds newest
computer scientist... it dosen't matter that they never did finish their
"quick sort" implementation back in intro.

Im no economist either, but I believe if our computer scientists would have
delivered during last decades tech boom, we would still be riding

Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[Wiggins d'Anconia]

drieux wrote:
On Friday, Jul 25, 2003, at 13:20 US/Pacific, Ovid wrote:

c. we find a way to cage the primates and leave the
land free for FriendsOfThePixies to roam freely across
the much happier land where no one ever changes the
Freaking Underlying Layer that they coded to...
Some would argue the primates are already caged... the problem, I think, 
is coaxing them there pixies out into the open...

http://danconia.org

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[drieux]

On Friday, Jul 25, 2003, at 13:20 US/Pacific, Ovid wrote:

--- drieux <[EMAIL PROTECTED]> wrote:
Great Questions!

MVC - Model,View,Controller

it is a design pattern, a way of 'looking at'
the problem and understanding which parts belong where.

Just to really fan the flames here and ensure that we're
not inadvertently creating innacurate memes,
[..]
The View in MVC is typically dynamically updated.
[..]
It's not always that way, but it's a far enough divergence
from classic MVC that the distinction is worth noting.
Anyone here who doesn't know that and starts
talking about MVC to a Design Pattern purist is going to
get a serious talking to :)
[..]
Silence is Evil
http://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid   
http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/
Ovid,

I love the smell of 'primate-ism' 

It could be merely the way that you are presenting the
problem - and a desire to defend an anachronistic model
of MVC, based upon the underlying 'primate-ism', and
the scary thought of 'recursion' in conceptual models
that might mean sticking the primate in a chair, and
leaving the heavy lifting to sentient life forms.
If we start with the premise that there can be but
one 'view' then of course that 'view' MUST be the
'view' that the Monkey^H^H^H^H^H^H Primate Sees.
So by definition we can 'rescue' ourselves from recursion.
So I am willing to question that opening premise, especially
given your own assertion that 'typically' - allowing that
there are manifestations of MVC in which the view need not
be dynamically updated.
But let us begin at the begining here, with the
OneTrueAndOnlyClassicallyPure - 'there can be but one view'
model of the MVC - and it gives rise to an application.
The Primate pokes it, and is amused.
Either all of software development ceases, or there is
the threat that a second application, built upon the
PureLand model of MVC arises, and so on and so on,
until there are many pieces of software, all with
'but one view'.
Along comes an integrator, and notices, that with a
replication of the basic paradigm, that information
from two TrueMVC's can be used to stitch together
a new synthetic MVC application. In this case of
course maintaining the TrueDoctrine, that the Primate
is the highest of all life forms, and that only the
view that the Primate Sees is the True View.
Never Mind that the little pixies inside the new
synthetic MVC application are looking at input
from the two 'true views' of each respective applications,
as if they were Primates, and spinning around quickly
and obligingly handing out the NewAndImprovedTrueView
to the Primate.
The downside to this approach towards MVC, besides
the scary thought that there are pixies in our
computers who might think of themselves as Primates,
and start scratching for fleas, leaving bananna peels,
and plotting to Go On Strike, or worse yet an LBO
to take over the firm and install their guy on the
Board is that it would mean 'empowering' the
pixies that deal with the 'TrueViews' to understand
what to do at 'upgrade time' - when the YUTZs decide
that a new element needs to be added or subtracted
to an underlying 'view'.
Now we have all watched Primates with their new
toy going - 'what does this big red button do?'
But Pixies, unlike Primates, of course are the friends
of sentient life forms who will RTFM, and make sure that
they know when, where, and why they want to press the
big red button.
Notice now, that the FriendOfThePixie who's 'view' has
changed is the only one who needs to be informed that
the 'view' has changed. All the Other Pixies, and their
friends, in the application - including the artsey one
who paints the pretty pictures for the Primate - can all
stay out late partying and running around while the
Poor Pixie who's view has changed must stay home, and
update their way of dealing with the fact that their view has changed.
So the FriendOfThePixie and the Pixie stay up,
drink much mountain dew, and mumble and swear about
the evils of the Freaking Primates and then check
all of the code back into the source code repository,
including the online documentation, knowing full well
that the Freaking Primate will merely go 'ook-ook'
and not read line one of it
Where does this leave us:

a. we allow for recursion in the MVC pattern so that we
can allow for software being built upon other software.
b. we demand that all software be written to bare metal,
and that it does not require little pixies with pretensions
to being flea picking primates.
c. we find a way to cage the primates and leave the
land free for FriendsOfThePixies to roam freely across
the much happier land where no one ever changes the
Freaking Underlying Layer that they coded to...
d. we remember to take the whole source code tree
and our co

Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[Ovid]

--- drieux <[EMAIL PROTECTED]> wrote:
> Great Questions!
> 
> MVC - Model,View,Controller
> 
> it is a design pattern, a way of 'looking at'
> the problem and understanding which parts belong where.
> 
>  1&q=Model%2CView%2CController&btnG=Google+Search>

Just to really fan the flames here and ensure that we're not inadvertently creating 
innacurate
memes, it should be noted that while PHP doesn't lend itself to MVC, neither does Perl 
when one is
talking about Perl/CGI.  The View in MVC is typically dynamically updated.  If you 
have a bar
graph of spreadsheet data and that data is altered, the graph, if a proper view, gets 
updated
automatically with no extra work on the part of the user.

However, your HTML typically won't do that.  Once it's rendered, it *usually* sits 
there, dumb,
until the user takes an action.  It's not always that way, but it's a far enough 
divergence from
classic MVC that the distinction is worth noting.  Anyone here who doesn't know that 
and starts
talking about MVC to a Design Pattern purist is going to get a serious talking to :)

Of course, many people who discuss MVC vis-a-vis Web programming are fully aware of 
this, but it's
so frequently understood that it's not always pointed out.

Cheers,
Ovid

=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid   http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[Teddy]

Please tell me what MVC means.

Thanks.

Teddy

- Original Message - 
From: Camilo Gonzalez <[EMAIL PROTECTED]>
To: drieux <[EMAIL PROTECTED]>
Cc: cgi cgi-list <[EMAIL PROTECTED]>
Sent: Friday, July 25, 2003 7:46 AM
Subject: Re: return(bless $rant, $class) || Fwd: PHP vs Perl


> drieux wrote:
> 
> >
> >
> > Todd either Paused for more MountainDew or had a Moment:
> > [..]
> >
> >> Those last two paragraphs were total rant,  and I probably
> >> have no idea what I'm talking about, but they are getting posted 
> >> anyway ;0)
> >
> > [..]
> >
> > I would like be so totally opposed to your
> > position if it were not for most of the dark horror
> > of where I so totally agree with you
> >
> > But First off - COOL RANT!
> >
> > p0: let us not confused science, technology and VOODOO.
> > Computer Science is wonderful for providing a theoretical
> > intellectual underpinning to hashing algorithms, while
> > a specific instance of that as a technology of course
> > is perl's 'hash' data structure, the actual 'coolness'
> > of course lies in using it in strange and arcane ways
> > that border on Voodoo.
> >
> > bless this ref...
> >
> > p1: Your complaint, amusement, at the gooder and
> > badder of Perl's OO modality, and it's usefulness
> > with providing 'name space management' is .
> >
> > return $ref_to_hash_of_function_refs ;
> >
> > p2: I am very nervous that folks are noticing that
> > at present PHP is not supportive of MVC as a design
> > pattern - and that may be a limiting factor - but as
> > you have also noted, given the gaggelation of globulated
> > together 'stuff' - eg: ASP+HTML+SQL - this means that
> > there are still great employment opportunities refactoring
> > that stuff into maintainable code. So we should support
> > the spread of PHP without MVC as a basis for more work
> > refactoring the code???
> >
> > return unless defined( $ref );
> >
> > p3: When folks go back and review when HTTP 1.1 came out,
> > and when further work on HTML 4.0 ceased in favor of
> > XHTML and the quest for tokens with X in it, a part of
> > the problem was a complete lack of any unifying standard
> > and/or any real idea what the core technologies are/were/willbe...
> >
> > die "undefined token" unless 
> > $web_service->reality_check(@cosmic_void);
> >
> > p4: given that hacking in perl does not require MVC as
> > a design pattern, but one can learn the hard way to support it
> >
> > ciao
> > drieux
> >
> > ---
> >
> >
> Okay, this is a beginner's list. What the hell is MVC? How do you hash 
> an algorithm?
> 
> 
> -- 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[drieux]

On Thursday, Jul 24, 2003, at 21:46 US/Pacific, Camilo Gonzalez wrote:
[..]
Okay, this is a beginner's list.
What the hell is MVC? How do you hash an algorithm?
Great Questions!

MVC - Model,View,Controller

it is a design pattern, a way of 'looking at'
the problem and understanding which parts belong where.


specifically you might start with

Which while a discussion dating back to the original
copyrighted date of 1987, and specifically aimed at
the 'smalltalk-80' - SHOULD be reviewed in any case
in which you have a 'presentation layer' - the view,
that deals with the graphical stuff, a controller
that deals with 'input' from the 'mouse,keyboard,etc'
and a 'model' that is 'changed' in in it's behavior
and/or content by the controller.
In theory 'HTML' was suppose to give us this
'common' presentation layer, and 'cgi code'
would give us a common approach as to how we
do the 'controller' foo but all too often
we all collectively zone out on 'what exactly
is the Model' that we are mangalating.
Too many of us have victimized ourselves
by trying to wedgie it all into one thing, rather
than respecting the 'differences' and so come back
to the 'original solution' and find it hard to clean
up what we messed up in the first place in the race
to 'get the product out the door'.
So a core part of why we keep bringing it back up
in groups like this is to point people in the general
direction of that 'solution' - and to remind them to
step back and review the basics from time to time.
As for hashing and algorithms, the idea is to remind
folks that there IS more than one 'hashing algorithm',
and all of that cool 'comp sci' stuff - about how to
handle things like 'hashing collision' - but that while
that 'intellectually coool stuff' is 'cool' at a purely
pedantic level, in the cold of the middle of the night,
it remains simpler to just get ANY hashing algorithm
into play - and perl has done a reasonably good enough
solution for most cases...
One of my pet FAVORITE tricks to use is a 'callForm'
key - where I hide the next in sequence value as a
'hidden input' and then use that in the code to
know which function/method to call:
if( defined($request) && $request =~ m/^POST|GET|HEAD$/)
{
my $queryString = ($request eq 'POST' )?
 : $ENV{'QUERY_STRING'};
my $qs = unpack_qstring_w_dupes($queryString);
my $formAction = {
stop=> \&doDaemon,
start   => \&doDaemon,
showOptions => \&showOptions,
hqConfigd   => \&showOptions
};

my $callForm = $qs->{callForm} || '';

$page = ( $callForm && defined($formAction->{$callForm}) ) ?
$formAction->{$callForm}->($qs) :
BogusBody( $qs, "HqConfigd_Horror",
"You Should Not See This"
);
}
being a basic form of the solution. the kicker trick
is that $formAction, which is a hash of functions references
that I will ultimately call with
	$formAction->{$callForm}->($qs)

Think of it as a mini 'OO' trick without the constructor.

Remember that in perl an "OO" thingie is merely a
blessed reference, that returns a reference to a
stack of methods and perchance some internal data stuff.
Most folks use 'hashes' solely as 'associative arrays'
unlike the usual 'array' where one 'indexes' into it
with an 'integer value' - a hash allows one to 'index'
into the 'associative array' with a 'key value' which
need not be an 'integer value' - and one leaves it up
to the 'hashing algorithm' to sort out where the
'value' is for the 'key'. In this case rather than
having say a 'string', we return a reference that
is the 'address' of some 'function/method'...
Where this can get 'totally psycho' is out at the
edge where it is faster, cheaper, and simpler to
it in the form:
 if( defined($request) && $request =~ m/^POST|GET|HEAD$/)
 {  
my $queryString = ($request eq 'POST' )?:$ENV{'QUERY_STRING'};
	my $query = unpack_query_string($queryString);

my $action = Wetware::Hq::URL_DB::db_get_actions();

$page = ( defined($query->{verb}) &&
exists( $action->{$query->{verb}})) ?
$action->{$query->{verb}}->($query) :
Wetware::Hq::URL_DB::Maint::check_maintenance($query);
 }
In this case, rather than implement the 'traditional'
model of a 'perl blessed object' - as if it were 'OO'
i just expressly call out a function that returns a
hash of references to functions, check first to

Re: return(bless $rant, $class) || Fwd: PHP vs Perl

[Camilo Gonzalez]

drieux wrote:



Todd either Paused for more MountainDew or had a Moment:
[..]
Those last two paragraphs were total rant,  and I probably
have no idea what I'm talking about, but they are getting posted 
anyway ;0)
[..]

I would like be so totally opposed to your
position if it were not for most of the dark horror
of where I so totally agree with you
But First off - COOL RANT!

p0: let us not confused science, technology and VOODOO.
Computer Science is wonderful for providing a theoretical
intellectual underpinning to hashing algorithms, while
a specific instance of that as a technology of course
is perl's 'hash' data structure, the actual 'coolness'
of course lies in using it in strange and arcane ways
that border on Voodoo.
bless this ref...

p1: Your complaint, amusement, at the gooder and
badder of Perl's OO modality, and it's usefulness
with providing 'name space management' is .
return $ref_to_hash_of_function_refs ;

p2: I am very nervous that folks are noticing that
at present PHP is not supportive of MVC as a design
pattern - and that may be a limiting factor - but as
you have also noted, given the gaggelation of globulated
together 'stuff' - eg: ASP+HTML+SQL - this means that
there are still great employment opportunities refactoring
that stuff into maintainable code. So we should support
the spread of PHP without MVC as a basis for more work
refactoring the code???
return unless defined( $ref );

p3: When folks go back and review when HTTP 1.1 came out,
and when further work on HTML 4.0 ceased in favor of
XHTML and the quest for tokens with X in it, a part of
the problem was a complete lack of any unifying standard
and/or any real idea what the core technologies are/were/willbe...
die "undefined token" unless 
$web_service->reality_check(@cosmic_void);

p4: given that hacking in perl does not require MVC as
a design pattern, but one can learn the hard way to support it
ciao
drieux
---


Okay, this is a beginner's list. What the hell is MVC? How do you hash 
an algorithm?

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

return(bless $rant, $class) || Fwd: PHP vs Perl

[drieux]

Todd either Paused for more MountainDew or had a Moment:
[..]
Those last two paragraphs were total rant,  and I probably
have no idea what I'm talking about, but they are getting posted 
anyway ;0)
[..]

I would like be so totally opposed to your
position if it were not for most of the dark horror
of where I so totally agree with you
But First off - COOL RANT!

p0: let us not confused science, technology and VOODOO.
Computer Science is wonderful for providing a theoretical
intellectual underpinning to hashing algorithms, while
a specific instance of that as a technology of course
is perl's 'hash' data structure, the actual 'coolness'
of course lies in using it in strange and arcane ways
that border on Voodoo.
	bless this ref...

p1: Your complaint, amusement, at the gooder and
badder of Perl's OO modality, and it's usefulness
with providing 'name space management' is .
	return $ref_to_hash_of_function_refs ;

p2: I am very nervous that folks are noticing that
at present PHP is not supportive of MVC as a design
pattern - and that may be a limiting factor - but as
you have also noted, given the gaggelation of globulated
together 'stuff' - eg: ASP+HTML+SQL - this means that
there are still great employment opportunities refactoring
that stuff into maintainable code. So we should support
the spread of PHP without MVC as a basis for more work
refactoring the code???
	return unless defined( $ref );

p3: When folks go back and review when HTTP 1.1 came out,
and when further work on HTML 4.0 ceased in favor of
XHTML and the quest for tokens with X in it, a part of
the problem was a complete lack of any unifying standard
and/or any real idea what the core technologies are/were/willbe...
	die "undefined token" unless $web_service->reality_check(@cosmic_void);

p4: given that hacking in perl does not require MVC as
a design pattern, but one can learn the hard way to support it
ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PHP vs Perl

[Todd W.]

<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> > 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..
>

I was thinking the same thing when I read that. Swap the first occurence of
'PHP' with the first occurence of 'Perl' in the paragraph and you have a
perfectly formulated reason of why you should use perl over PHP !!??!!

It says, "PHP has a less confusing and stricter format without losing
flexibility." Which is fine for printing environment variables to a browser,
but the second you try to do something like implement a MVC pattern ( which
is the way one is supposed to develop distrbuted applications, but is
inherently anti-PHP ) the language proper becomes as flexible as a 12 inch
piece of 2x4, so you're left with nothing but a prop or a VERY crude hammer
=0).

I went to a consuting firm, and they had this app with 50 different files of
ASP+HTML+SQL, all mixed together, and they said they wanted a pocket IE
interface to the app. I said okay, the first thing we do here is right
click -> delete on the parent folder. They said no. I asked them how they
wanted me to do it, and they wanted a new folder with the same files except
for this ASP outputs the PIE interface. I'll pass.

But you know, to each his own. During the opening talk at YAPC::NA this year
Conway had slide that contained a list of 10 or so bullets explaining why
perl 5 OO is good. And on the very next slide used the exact same 10 bullet
list to illustrate why perl 5 OO is bad!?! I think this boils down to Wall's
philosophy of post-modernism. I'm no sociologist, and what I've learned of
post-modernisim has been from Wall, but I understand, post-modernism as
"this AND that" as opposed to "this OR that".

And I agree with him. perl 5 OO boils down to a builtin ( namely, bless() )
that tells a reference that all subroutines in the package named in the
second argument are its methods. Now one can write some pretty cool code
with that, using a fraction of the disk space that the C# implementation
would require.

But try translating that to a monkey coder, or that high schooler you
mentioned that is happy getting paid in soda. Why become a real computer
scientist and learn about polymorphisim or hashing algorithms when you can
crack another mountain dew and pound on a keyboard for awhile. So what if
the development time is 6 months over schedule. Just add another semester of
VC++ 6 and, voila, a shiny piece of paper declaring the worlds newest
computer scientist... it dosen't matter that they never did finish their
"quick sort" implementation back in intro.

Im no economist either, but I believe if our computer scientists would have
delivered during last decades tech boom, we would still be riding the wave.
I mean, come on, is Napster _really_ the only technology we got out of the
90's? And if it truly was, why couldnt we sift a killer B2B app out of it?
Mabye its our fault for a different reason. I mean, shoudn't we have stood
up and said, "Hey, theres really no point in investing a billion dollars in
something like bluejeans.com.?"

Those last two paragraphs were total rant,  and I probably have no idea what
I'm talking about, but they are getting posted anyway ;0)

But back to the ( or at least my ) concept of postmodernism. PHP has been a
great advocate for the web and is truly maturing very quickly. I doubt if
the Apache Foundation would have incubated it if it weren't. My latest PHP
interpreter even compiled with built in GD support, and really, its pretty
neat. And with web services ( possibly ) becoming the ultimate postmodern
software concept, I really dont care what its written in.

Todd W.



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PHP vs Perl

[drieux]

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 -
 - did the graphics
 - 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. laziness
But 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 req

Re: PHP vs Perl

[wiggins]

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
> 
>
>   4.01
>   8049
>   1
>   8347
>   2333
>
> 
> 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:
> 
>
>   xanana
>   libex
>   jeeves
>
> 
> 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 tha

Re: PHP vs Perl

[drieux]

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
	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.
As such we have all been improvising ways to 'woof Up Html Stuff',
whether in PHP or Perl... All too often, because someone saw
a web-page somewhere, and it did something like this doodle
on a cocktail napkin { make sure that you talk with the
graphically enabled person when getting 'what the customer
really wants' - ESPECIALLY if the customer is both colour
blind, has no sense of spacial orientation, and generally
is not into 'graphics'. Ok, you should also make sure that
they have been on Planet Earth LongTime, and didn't just
fall off the MotherShip, YOU try to get a collection agency
going after a Klingon who loves opera, but can not sing well... }
Then there is the problem that anyone with a decent
"Graphics Package" can whip up gifs for buttons,
and make really cool things that will work as a 'mock up'
of what the Human Interface 'should look like' - but this
only gets you to the 'mock up' - and while that helps at
the level of having the Customer go 'ook-ook, look pretty'
this is where the 'cgi stuff' gets 'ugly' - since if it
really is a 'middleware' solution - that is bridging
between the 'cool graphics' at the browser side, and
any level of technical complications back at the server
side - then you have to start making decisions about whether
or not you want to cache information in cookies, or do you
use hidden values, or what to pass information around - On Top
of the basic 'select from menu' and 'click check boxes' and
'fill in the form' processing.
In short 'how dynamic' is the 'dynamic webpage' that you
are creating - and what is the 'underlying stuff' that one
is grongelating through, or trying to do.
Those Mock Ups will help solve at least the 'presentation'
portion of the problem - both in terms of how to get the
person poking the page to poke the right things, as well
as how you return the 'response' to their poking and proding.
[..]
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
  
4.01
8049
1
8347
2333
  
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:
  
xanana
libex
jeeves
  
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...
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!
I think that a lot of folks can tell a PHP driven 'web site' -
just as more and more are able to ID wiki sites - from a full
tilt tomcat java server site from an Adobe GoLive site...
And for those who happen to connect to

	http://localhost:631/

to connect to their CUPSd they should crawl int

Re: PHP vs Perl

[Wiggins d'Anconia]

Octavian Rasnita wrote:
Hi all,

Talking about PHP, someone asked me to tell him why is PHP better and why it
is used more than Perl.
I don't know what to tell him because I don't know PHP, but I've seen that
it is used more and more and I guess that there are more PHP scripts than
Perl scripts now, so I think he could be right.
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 ;-). The 
reason why this is a flame war question is because no right answer 
exists. 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. 
 There are all range of PHP/Perl advocates that can spout off a list of 
reasons why one is preferred to the other, but the ones that understand 
them the best are the ones that don't say anything because they know 
that there is no reason to argue in the first place.  They also know 
that there is no true way to gauge how much one or the other is being 
used, so to say that one has more market/mind-share than the other is 
sillier than debating which one is better, not to mention that even if 
one could gauge this, would it really change what is best for you 
because more people are using the other?  Way more people use Windows 
than Linux, does that make it better for me?

Of course we all know the real truth, Vbscript/ASP/.NET is *clearly* the 
best... that will be $300.00 please...

http://danconia.org

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PHP vs Perl

[drieux]

[..]
Talking about PHP, someone asked me to tell him why is PHP better
and why it is used more than Perl.
[..]

This might be a good time to point people towards the

	MVC - Model, View, Controller

approach for doing software development.
{ just google search on Model, View, Controller for fun }
Web-browsers are a way of presenting a 'view' of
the 'model' - and the web-browser dialogs with
the web-server to 'get stuff done' - this may
mean using the 'common gateway interface' (CGI)
to pass stuff back to a 'controller'
That controller may be written in perl, it may
actually invoke code that is NOT written in perl.
It might be written in PHP, that understands how
to invoke things written in perl and other languages.
As we have discussed in terms of 'using java scripting'
there is actually a level of 'MVC' that is strictly at
the browser side - and that the server side needs to be
able to deal with the 'failures' that occurred because
the 'java scripting' was ignored, and 'stuff' came
back to the server side - and needs to be managed
by either the CGI code itself - or by the underlying
stuff that it rests upon
So a part of the problem is

how tightly wrapped is your 'web-browser side'
MVC to the 'server-side' MVC(s); and how tightly
coupled is your 'server-side' MVC's to each other...
At which point we start noticing that there are
'design sillies' in which we forget that the
'server side' is laying on top of other MVC's,
such as database queries, CLI invokations, proxy-ing
through other web-services
IF one started with a clean, clear and consistent
interface for each MVC on MVC, on MVC, then of
course those will all align correctly and all
will be fine, at least in theory
Allow me to offer an actual case study. I started with
a general 'abstraction layer' that said
I need a database thingie, somewhere,
and I will make my queries to it using a
CGI based solution.
This way, all of the 'cgi code' that is directly
invoked by the user - calls code that itself will
turn around and query some other web-server as if
we were a 'web-browser' doing a
	GET http://some_db_host:db_port/some/path/db_cgi.cgi?verb=doFoo&val=bob

get the answer back, stuff it into some html
wrappings, and push it out STDOUT to
the user's web-browser.
This allowed me to work out the basics of
what sort of DB I really wanted - so when I
decided what to use at the other end of that query,
I could swap it IN, without changing line one of
the 'cgi code' that the user will invoked.
{ as a general rule, I like to stuff the 'do the work'
side of the problem in a 'perl module' that is external
to the foo.cgi - so that modifications can be done external
to the 'foo.cgi' itself... }
We could of course go the other way with this,
and decide that for 'presentation purposes'
calling a PHP was 'much cooler' - then all I
need to do is teach the PHP to go fetch the
stuff from the DB by using a step in the process
that either knew how to invoke a CGI connection
with another web-server, or invoke some piece
of perl bridge code built with the lwp-useragent,
or roll up something that understood how to open
a socket, woof stuff down it, get a message back,
deconstruct it
Ok, I must complain here there is that other
part of the HORROR STORY - where your beautiful
web application gets 'attacked' because
	"well it's just a 'check box'."

So now one has to 'just' add

"Sysnames (-S):\n" .
'' . "\n";
to the presentation layer, except of course that also means
updating the java-script to adjust for the shift in fields
of type foo, and then the back side of that cgi code has
to actually pick out the 'S' value, if it exists, then
of course one has to re-write the Freaking Controller,
to figure out how to pass that smack on through to
the CLI interface, so that it will be used, plus the
extension to that Module, to handle all of the new
classes of ERRORS that can occur, because one did
or did not pass that additional set(s) of argument(s),
with or without the newly restructured pre-ceeding Smack,
because the vendor's CLI MVC shifted more than the
	"it is just a "check box" thingie widget..."

Or should I just say, there are other more sinister
plots and conspiracies to really feast upon
than whether you want PHP or Perl to be the
primary source of the 'html like stuff' that
goes back to the user's browser...
ciao
drieux
---

ps: did I mention the part about having to shift
all of the 'online html based documentation' that
goes with the application that will also have to
be clarified where all of the previous illustrations
have been obsoleted by the addition of 'just a checkboxThingie'
not to mention the additional work of providing the primary
documentation about how the user should use it, plus
all of the new error/exceptions that can be thrown,
caught, missed, could barf all the way back to the browser...
pps: is it worthwhile to warn coders to make sure
that thei

RE: PHP vs Perl

[Scot Robnett]

Oh my lord, you didn't really start a "which language is better" thread, did
you? Time to set up another e-mail filter over here...have you no sense of
decency, man? heh heh

-
Scot Robnett
inSite Internet Solutions
[EMAIL PROTECTED]



-Original Message-
From: Octavian Rasnita [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 22, 2003 4:40 PM
To: [EMAIL PROTECTED]
Subject: PHP vs Perl


Hi all,

Talking about PHP, someone asked me to tell him why is PHP better and why it
is used more than Perl.
I don't know what to tell him because I don't know PHP, but I've seen that
it is used more and more and I guess that there are more PHP scripts than
Perl scripts now, so I think he could be right.

Of course, he was talking about CGI programming, because I know that Perl
can do much more than CGI programming like PHP.

Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: PHP vs Perl

[wiggins]

On Wed, 23 Jul 2003 00:39:30 +0300, "Octavian Rasnita" <[EMAIL PROTECTED]> wrote:

> Hi all,
> 
> Talking about PHP, someone asked me to tell him why is PHP better and why it
> is used more than Perl.
> I don't know what to tell him because I don't know PHP, but I've seen that
> it is used more and more and I guess that there are more PHP scripts than
> Perl scripts now, so I think he could be right.
> 
> Of course, he was talking about CGI programming, because I know that Perl
> can do much more than CGI programming like PHP.
> 

Can you say hello to Pandora for me...

The only sure answer to this is that Vim is better than Emacs.

Let the flaming begin!

http://danconia.org

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

PHP vs Perl

[Octavian Rasnita]

Hi all,

Talking about PHP, someone asked me to tell him why is PHP better and why it
is used more than Perl.
I don't know what to tell him because I don't know PHP, but I've seen that
it is used more and more and I guess that there are more PHP scripts than
Perl scripts now, so I think he could be right.

Of course, he was talking about CGI programming, because I know that Perl
can do much more than CGI programming like PHP.

Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]