4 ms·

Sure. Social networking sites like the one in my user profile. Pretty much any site where the building of the site would be fairly trivial in any language, an

Sure. Social networking sites like the one in my user profile. Pretty much any site where the building of the site would be fairly trivial in any language, and scaling is the problem: with PHP, you can start it on any cheap host and port it in minutes to better servers, because you don't have to worry so much about setup. If the idea itself is innovative, but there's nothing interesting about the code that the site runs on, PHP is an excellent candidate. I've built sites (some for clients, some of my own) in a bunch of languages, and there's a certain amount of tradeoff between setup/installation and actual coding. For whatever reason, languages which are more fun or more productive to code in require more setup time, and are likely to be already installed on a random new server almost exactly in reverse proportion with how fun/productive they are. It's eerie.

jrockway 18y ago
Pretty much any site where the building of the site would be fairly trivial in any language, and scaling is the problem: with PHP, you can start it on any cheap host and port it in minutes to better servers, because you don't have to worry so much about setup. Aren't most PHP apps dependent on weird php.ini settings? And anyway, the "real" langauges are equally easy to deploy. Get yourself a $20 slicehost account (to start with), add two lines to apache's config to enable FastCGI, then just copy your app up to that server. That's all there is to deploying Perl, Ruby, and Python these days. With Perl and Catalyst, I can "make catalyst_par" and get a file that contains the entire application; including the version of Perl I am developing with. That way I know for sure it will work when I copy it to production. (Yes, this means I have to use the same architecture for both development and deployment. I do.)
- randallsquared 18y ago
  Weird php.ini settings can almost always still go in the directory with the php files, so just copying the directory automagically makes everything work right. Some settings don't work this way, of course, but I'm not sure which those would be, offhand. If you're using Python, for example, you're probably also using some framework... for years I used Webware for Python, and more recently web.py. Both require careful attention to get working in a convenient fashion, in my opinion.
- jamesbritt 18y ago
  " That's all there is to deploying Perl, Ruby, and Python these days." And scaling with those languages is a solved problem.

jrockway 18y ago

Pretty much any site where the building of the site would be fairly trivial in any language, and scaling is the problem: with PHP, you can start it on any cheap host and port it in minutes to better servers, because you don't have to worry so much about setup. Aren't most PHP apps dependent on weird php.ini settings? And anyway, the "real" langauges are equally easy to deploy. Get yourself a $20 slicehost account (to start with), add two lines to apache's config to enable FastCGI, then just copy your app up to that server. That's all there is to deploying Perl, Ruby, and Python these days. With Perl and Catalyst, I can "make catalyst_par" and get a file that contains the entire application; including the version of Perl I am developing with. That way I know for sure it will work when I copy it to production. (Yes, this means I have to use the same architecture for both development and deployment. I do.)

randallsquared 18y ago
Weird php.ini settings can almost always still go in the directory with the php files, so just copying the directory automagically makes everything work right. Some settings don't work this way, of course, but I'm not sure which those would be, offhand. If you're using Python, for example, you're probably also using some framework... for years I used Webware for Python, and more recently web.py. Both require careful attention to get working in a convenient fashion, in my opinion.
jamesbritt 18y ago
" That's all there is to deploying Perl, Ruby, and Python these days." And scaling with those languages is a solved problem.