Lars Kelto wrote:
I think that PHP is a lot easier to install and use for the average
user/programmer. Maybe more importantly, it is easier to install PHP
apps on an ISP's server. Embperl is easy to install, but mod_perl can
be tricky and you have to be somewhat of a guru to understand it and
use it's power. That is why PHP's popularity is growing much more
rapidly than mod_perl.
I agree. PHP solves small problems fast, is implemented and learned
quickly, and is widely supported. I think of mod_perl/embperl as my
'power tools' for my projects with dedicated servers and need for robust
applications, which is most of them.
A good question might be, is there anything we can do to encourage
support for mod_perl/embperl on hosts? Also, could we assemble a list
of hosts who are known to support them well? Someone interested in
trying embperl may be more likely to choose it if finding a host is easier.
That's a good point. Another question that occurs to me is, How many *new* programmers (i.e. young
and learning about new stuff) are turning to mod_perl and Embperl? It seems to me that most people
using these tools started programming a while back. The sign of health for a technology is how many
new, young programmers it is attracting, rather than how many older, experienced ones it already has.
PHP and Java both appear to be a fait accomplis, they have already achieved dominance in the same
way that MySQL has already achieved dominance over PostgreSQL, even though it appears that
PostgreSQL may be the more robust and complete solution (though I admit I haven't had time to
investigate this myself, it's just what I hear repeated over and over by PostgreSQL people).
I think that people looking for the simpler, "beginner" solution turn to PHP, whereas the heavier,
"enterprise" users tend to go to Java. So maybe mod_perl/Embperl is stuck somewhere in between in a
kind of no mans land, perceived neither as beginner nor enterprise level. That's a shame, since we
all know there really isn't anything that Java can do that mod_perl/Embperl can't. But I don't want
to be in the position of sour old programmer crying into his beer about how he "coulda been a
contender" but backed the wrong horse. I'm increasingly getting nervous about basing my programming
experience on something that seems to not have the mindshare in up and coming young programmers.
I know from history that it's not always the "better" solution that is successful, but rather the
one that makes itself easier to use, more accessible to new users, and just all round simpler. I
don't really see what is so hard about installing mod_perl, because most Linux distributions of
apache seem to include mod_perl in the package list, along with php. However, you're right that
third party hosts perhaps do not include it as much. Or if they do, then people using a shared
server (without root access) won't be as able to install their own perl modules - I experienced this
myself just last week, when I had to do a little search engine for someone. I wasn't able to install
Embperl on the server, so I ended up using a small cgi instead (it gets little traffic, so the
efficiency thing doesn't really matter all that much). PHP was available by default, of course.
Advocacy for tools like mod_perl and Embperl may be a way to go, but it can't really replace "buzz"
in the developer community. I think we lost a lot of that "buzz" when we (as a developer community)
took a massive time out to develop the incompatible Versions 2 of Apache and mod_perl. People kept
hearing that it wasn't ready yet, and so they used something else. But that's not the main reason, I
think. PHP just gained mindshare because it was so simple and cheerful. It's a lesson to geeks who
think all that matters is technical superiority. If we spent more time making our projects easy to
use and accessible to new users, rather than adding obscure, complex new features that hardly
anybody uses, then maybe our projects would be more widely adopted.
Just my opinion!
-Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
