geoff writes "According to Security Space, mod_perl is installed on almost 37% of all Apache servers, growing nearly 20% during the month of August. mod_php, on the other hand, was down almost 4% in August to a 39% share. Of particular interest is that mod_perl has seen a significant rise in the past year, while mod_php seems to have been relatively flat during the same period. cool."
The tone of the posting confuses me. Are we merely cheering for mod_perl (something I can get behind), or are we also cheering for the non-increase in the use of mod_php? If so, why?
I don't use mod_php, but I know that it has its weaknesses. It also seems to get more shit than its due among Perl programmers. For a programmers of a language that revels in the multiplicity of ways of doing things, I wonder why the schadenfreude. Or am I just imagining it?
Now if we were talking about ASP...
Re:Do we hate mod_php?
geoff on 2002-09-07T00:33:12
all I was trying to say was that it is pretty cool that mod_perl is finally catching up to PHP in this particular statistic.
of course, my bias toward mod_perl for web application development is obvious, so it's only natural that I hope to see mod_perl in the number 1 slot:) Re:Do we hate mod_php?
bhann on 2002-09-07T16:49:37
I've got to say that most often when talking to PHP "developers" I'm on defense.
Most seem to want proclaim things such as PHP's amazing ability to split strings on a pattern, or something like that.
Even in my job perl comes across as an "old" language, unusable for todays modern tasks. Of course the sheer amount of projects we have going kinda refutes that argument:) Re:Do we hate mod_php?
m2 on 2002-09-08T10:28:44
I've got to admit I have strong feelings against PHP. My introduction to PHP happened during the PHP 3 to 4 transition and it was more or less an exercise in self teaching. The project was nothing but a smallish in-my-free-time database-driven website developed from the ground up. The reason why PHP was picked is that other people involved in that project already had experience with PHP (and one or two where self-proclaimed Perl haters).
To make a long story short, my frustration with PHP grew continously. The language is amazingly ridig and I had this constant feeling its designers were trying to "make Perl right". For anyone with a passable Perl knowledge, it's quite clear PHP draws visibly from Perl, but, and this is the crux of it, it "corrects" Perl. There Is Not More Than One Way To Do It. Usually there's only one. I guess that makes it easier for people to learn it, because when they ask Joe, they get about the same answer they would get from Mary. But for me the downside is that things tend to get painfully verbose.
That alone wouldn't be a reason to hate PHP... but sooner or later you'll face PHP's largest weakness: the database API is horrendously inconsistent -- which IMO only reflects the whole picture. After programming with PHP for a while, you have got to ask yourself Why do I do this this way if I'm dealing with Foo but in different way when I'm dealing with Bar even if Foo and Bar are very similar? Regarding the DB API, in the mean time things have got better, someone rolled up the sleeves and wrote a DBI-like thing, but I've never actually used it. But the underlying issue remains.
Having said that, some people complain about Perls' OO system. They obviously haven't seen PHP's. With the right direction Perl's evolves from "Huh?" to "Wow!" (thank you Damian). PHP's will always remain at the "yuck!" level. PHP's isn't anything but namespaces -- go ahead, try to implement a singleton pattern in PHP (but please keep all your razors and pointy objects locked down, I don't want to feel guilty if you commit suicide while you are at it).
Put all that aside if you want. PHP's swiss-cheese security record should be reason enough to keep away from it.
'nuff ranting.
Re:Do we hate mod_php?
jeppe on 2002-09-10T11:33:39
I used PHP, then came to Perl through work. PHP is nice for making quick and easy web applications. It is true that the DB API is horribly inconsistent, but making a webapp that's plug'n'play between different RDBMS by experience will need some specialized functions anyway. But if you are willing to tie to one RDBMS, then it's not that bad.
Also, remember that coming from one language to another, you tend to bring with you luggage. Although we as experienced developers like the total freedom in Perl, programming novices are likely to be confused by the wide array of ways of doing one thing. Total freedom without maturity is doomed.
End of the story is that I created a nice little Time Sheet app with mysql in the bottom, and it ran rather quickly on a sickly old P90 w 64 megs of RAM.Re:Do we hate mod_php?
KLB on 2004-09-27T12:47:06
I am a Java developer (specialise in websphere ee app development). I am also a lead developer for a multi dev culture in an international merchant bank. Although java been my core, I have had much experience in integrating other cultural dev languages into our environment(ie php, perl, vs, dotnet, etc). Unfortunately I don't see the problems you are complaining about in php as they are common to all environments to some degree or other. Our approach is to apply our architected abstraction layer to the technology we use, provided it can support(php, pearl, java, dotnet, etc). The rest of our architecture then plugs directly onto it. In other words I would be seriously concerned if one of my developers were writing their own db calls... we have set simulations to ascertain which languages perform with which loads ... surprisingly the php/mysql combo comes out with on average 22% performance gain, not matter what the load above our next competing language dotnet and being a java professional by nature, I am sad to say 26% above that of our java technology. But then we are using an OODB with RDBMS combo. Give it a thought if its worth it, and refrain from an architecture where developers still write their own db calls.
Re:I'm one of the numbers
epivera on 2002-09-07T02:05:43
I almost forgot: PHP has had some security issues recently, I think one from simple HTTP POSTs.Re:I'm one of the numbers
m2 on 2002-09-08T10:33:11
That probably has much to do with the mod_php decline. Lots of, ehem... "administrators" have PHP installed and active without even knowing about it. Last time I looked at it, SuSE's default installation liked to throw in Apache with PHP just for the fun of it. I figure there's lots of sites out there that having read a PHP security advisory have gone "don't worry, we don't have PHP insta... oops."
another PHP server to be crushed tonight.
nicholas on 2002-09-12T10:11:26
That probably has much to do with the mod_php decline. Lots of, ehem... "administrators" have PHP installed and active without even knowing about it. Last time I looked at it, SuSE's default installation liked to throw in Apache with PHP just for the fun of it. I figure there's lots of sites out there that having read a PHP security advisory have gone "don't worry, we don't have PHP insta... oops."tsunamii.net are crushing web servers in the name of art. Interestingly, the server that is going to be crushed in London tonight is running PHP
Someone on the london.pm list did an nmap scan on another of their artworks, and they've got tons of ports open, including
chargen
,pop-3
andsunrpc
. It would appear that they're using a default Linux distro, and making no effort to lock it down. (Not wise, considering that someone could hack their "art" to trigger the crusher earlier). In which case, it would appear that this distro also has a PHP enabled webserver as one of its out-of-the-box defaults.Netcraft do a second estimate of server software based on sites in use (to elimiate bias due to domain parking servers counting thousands of times). Are there stats based on the number of in-use sites running mod_perl, PHP, etc?
Re:"cool" not cool
kwilliams on 2002-09-09T03:27:01
I think you're reading a bit much into this. It's quite reasonable to compare one product to its nearest "competitor" in order to see how relative market/mind share is changing over time. I don't know of a much better comparison for mod_perl than PHP, because they tend to fill similar niches even if their capabilities are pretty different. So I think it's possible to use PHP as a benchmark of mod_perl's success, without casting any ill will toward PHP. That's how I read the OP, anyway.
I don't think Geoff meant to imply any "greatness" conclusion either. I think we've all seen enough usage ratios be out of sync with product goodness ratios to infer such a thing.
Re:"cool" not cool
darobin on 2002-09-09T09:26:23
Knowing geoff I think you read more into his words than he meant, I doubt that he was attacking php as such. The point is that php is number one, and has held that position for ages. The fact that we're 2% behind means that we're number two and that we're close to becoming number one. Also, our growth while others stagnate means that modperl is very much gaining ground (as opposed to just maintaining itself in a growing universe).
I think this is great, and I really hope there'll be someone to make a press release if/when modperl becomes number one. We could really use the advertising.
Re:"cool" not cool
ziggy on 2002-09-09T13:02:12
I think that the issue is less we're (almost) #1!, as much as mod_perl is very popular.The fact that we're 2% behind means that we're number two and that we're close to becoming number one.I've known developers who are faced with a decision to develop with either PHP or Perl/mod_perl. A few years ago, many of them chose to use PHP simply because it was more widely adopted. Now, that is no longer the case.
Re:"cool" not cool
darobin on 2002-09-09T20:49:46
I think that the issue is less we're (almost) #1!, as much as mod_perl is very popular.
Yes of course, but Number One has that extra market ring to it
;-) Re:"cool" not cool
brevity on 2002-09-10T00:11:47
Yeah, I can believe that. There's a definite ceiling with PHP, unlike perl.
But, I think I agree with the comment made (deep in another thread) about how people are just *turning off* their default-install PHP due to security issues.