Lessons to be learned from PHP
SEE ALSO: PHP’s shareability brings all the boys to the yard
I’ve been reading this latest thread of posts around the net concerning Ruby and shared hosts, or equivalently, ease of installation. Here’s one. Here’s another. And I’m glad, for Ruby, that they are talking about this problem - I hope for their sake they take it seriously.
The history is this: first there were the dinosaurs, then there was the web. Then there was cgi scripting. Then there was perl and mod_perl which solved the performance issues that came along with cgi scripting. For awhile, that was the best game in town (according to me :). PHP, though, came along with a breakthrough idea - mod_php was an everything in one install. Unlike mod_perl, mod_php gave you a programming language, templating language and extension all in one. Once you installed it, you started making your .php pages and everything just worked.
mod_perl on the other hand, gave you nonesuch. In addition to installing mod_perl, you needed to select your templating language out of a myriad of options, install that as well, pick a file extension, then configure your apache to do the right things to the right files. mod_perl, of course, gives you much more power than mod_php - since mod_perl provides full access to all levels of the Apache API. The thing is, though, that most people, most of the time just want to make web pages.
The other thing that PHP did is make everything part of the core language. Everything. This has the nice effect of making it dead simple to use because there’s just so much functionality built right in. Of course, ultimately, this is a terrible language decision because you get saddled with tons and tons and tons of functions that you have to continue supporting and since PHP doesn’t have namespaces… Witness the problems when using PHP and mysql where you have a choice of three things, all built into the language - mysql, mysqli and now a move to PDO (their new DBI based system). Witness also the craziness that is their specific database method calls and how every conceivable action you might want to take was built in as a full on function but not uniformly across the different database specific functions… seriously, there’s an ibase_create_user function - with no counterpart for the mysql/mysqli versions.
I don’t think anyone is suggesting that PHP is a beautiful language, but it is one rooted in practicality and the needs of the bulk of web developers around and its vibrant community and wealth of applications and modules are a testament to that. I think that any languages that aspire to that level of popularity would be well served to take it into serious consideration.
Ruby has a system even more convoluted than mod_perl. That it wants its own web server that isn’t Apache is mildly (and by mildly, I mean completely) crazy. I’d say to continue their upward uptake (if indeed they are still in an upward trajectory) they need to simplify.
I wouldn’t mind seeing the Perl community do the same. I for one, would love a mod_mason that took mod_perl and bundled it with mason, DBI and DBD::mysql for a more all in one approach. Hmm… I wonder what’d be involved in that…
SEE ALSO: PHP’s shareability brings all the boys to the yard
January 12th, 2008 at 11:16 am
mod_python, anyone?
January 12th, 2008 at 11:17 am
Also that coComment thing is totally weird and confusing.
January 12th, 2008 at 11:19 am
Oh sweet, looks like there is already a mod_python. Now to learn python to a reasonable degree :]
January 12th, 2008 at 11:21 am
James - yeah, I’m not sure about this coComment thing, I may take it off. As for mod_python - I’ve been curious to check it out, haven’t done any Python in years (and I didn’t love it when I did it) but with Python 3 around the corner I may do a little reinvestigation…
January 12th, 2008 at 11:32 am
“Ruby has a system even more convoluted than mod_perl. That it wants its own web server that isn’t Apache is mildly (and by mildly, I mean completely) crazy.”
This isn’t true. You’re probably talking about Rails, which Ruby is not. Ruby scripts are usually run one page at a time, just like PHP.
January 12th, 2008 at 11:57 am
Yes - that’s true, technically. But in my experience when I hear of any Ruby web development it is always in the context of Rails, for better or for worse. This is an honest question, as I am not steeped in Ruby - is there any significant developer base for non-Rails web development in Ruby?
January 12th, 2008 at 12:28 pm
[...] Over at deasil.com there is a well argumented post on Lessons to be learned from PHP. [...]
January 12th, 2008 at 1:59 pm
If you find a better designed (and simpler to implement and deploy) web framework than Django http://www.djangoproject.com/ - let me know.
January 12th, 2008 at 2:17 pm
[…]I wouldn’t mind seeing the Perl community do the same. I for one, would love a mod_mason that took mod_perl and bundled it with mason, DBI and DBD::mysql for a more all in one approach. Hmm… I wonder what’d be involved in that…[…]
I don’t understand. How does CPAN not achieve this already?
January 12th, 2008 at 2:39 pm
OH CRAP — another article with ignorant comments about PHP’s global namespace pronouncing “this is a terrible language decision” and giving the reason “because you get saddled with tons and tons and tons of functions that you have to continue supporting.” Ooohhhhhhh … those nasty PHP developers forcing the world to forever support optional compiled in libraries … save us all! And how will we ever make the choice of which one to use! Help .. help!
If you don’t like PHP’s share nothing architecture (or don’t understand it more likely) then just say you prefer something else.
And for the record, I think a well implemented mod_ruby would would be awesome.
January 12th, 2008 at 4:02 pm
No you totally misunderstand it. Mod_php was successful because it allowed individual users not to stop all over their own scripts and other people’s scripts. Mod_perl is hard to deploy in a shared environment because of this.
Mod_php was then used on shared hosting hosts with cheap hosting, the hosting that teenagers and entry level web people could afford. Even today it is rare you get to use mod_perl on a webhost not because perl isn’t popular, but because mod_perl doesn’t work well in a multi-user shared webhost environment.
January 12th, 2008 at 6:41 pm
Django is a beautiful framework, but deployment is still a pain in the ass. Python frameworks are just a hair’s width easier to deploy than Ruby frameworks.
Nothing compares to PHP when it comes to deployment - which should be the goal for all Python and Ruby frameworks - upload and forget it.
January 12th, 2008 at 7:10 pm
“This is an honest question, as I am not steeped in Ruby - is there any significant developer base for non-Rails web development in Ruby?”
Same anon here: yes, there is. Ruby has a CGI module, like PHP (and like most other languages out there) for you to script it like said language. Ruby has a templating module, for you to template HTML like PHP doth template HTML.
Please, stop thinking Ruby => Rails. Ruby is a fine language; if you don’t like Rails, don’t let go of Ruby.
January 12th, 2008 at 8:53 pm
[...] about deployment (and for Django, and lots of other posts too), people are thinking about PHP a bit more analytically. I think people mostly get it [...]
January 12th, 2008 at 9:55 pm
[...] a new post to the blog at deasil.com, they talk about some of the lessons they see that can be learned from [...]
January 13th, 2008 at 6:54 am
[...] short followup to my PHP post from a couple days back… It spawned some interesting comments that got me thinking some more on the subject. Another post I came across pointed out some other [...]
January 14th, 2008 at 12:50 am
[...] is also true that PHP builds everything in. And like the author says, it might be a terrible decision for a programming language, but it [...]
March 5th, 2008 at 6:49 am
php 6 on the way
http://www.w3answers.com