4 ms·

I agree with this. Deployment of Perl was a pain in the ass. With PHP you literally just FTP’d the files to your normal web directory and you were off to the ra

I agree with this. Deployment of Perl was a pain in the ass. With PHP you literally just FTP’d the files to your normal web directory and you were off to the races. Even today PHP still has that advantage over many other languages. To my knowledge even now you can’t just upload a bundle of .py, .rb or .jar files into a directory hosted by Apache and go. That being said these days the other languages become their own http server and are usually fronted by a reverse proxy or two. But still that is like an order of magnitude harder to stand up than PHP.

tyingq 6y ago
You can set up such that newly uploaded Perl, Python, etc, scripts are runnable as soon as you put them there. But, typically, you're using a template framework or other dependencies and don't want those things exposed to the web server. PHP initially worked well that way because you lumped your templates and code into one file.
shagie 6y ago
Back in days of old, I would upload a bunch of perl files into the cgi-bin directory for the server... or files that ended in .cgi into wherever in the htdocs directory. With some juggling of what the script that was the .cgi, it would have been trivial to make it launch Java and consume the data... but Java wasn't set up for that (and the startup times for a Java cgi would have been nightmarish).
Evidlo 6y ago
> To my knowledge even now you can’t just upload a bundle of .py, .rb or .jar files into a directory hosted by Apache and go. Doesn't that just depend on Apache settings? You can set up Apache to serve all requests ending in .py as CGI. As long as these scripts emit HTML the situation is the same as PHP.
- darrenf 6y ago
  Small nitpick: it doesn't, and never had to be, HTML that was emitted. Executables were/are responsible for headers (including `Content-type`) as well as the body.
  - shagie 6y ago
    An example of this was the old, classic, counter.cgi which, when accessed would: * Read a file containing an integer * Increment the integer in memory * Emit a .gif with the new value * Write the new value back to the file
    - anyfoo 6y ago
      That's a bad order to do things, is that how it worked? There is a huge window while emitting the .gif during which other visitors may appear. At best a new visitor appearing during another visitor's "emit gif" phase does not increment the counter, at worst a visitor on a very slow line causes the cgi instance for this visitor to run for a long time and then write back a very old value to the file, making the counter run backwards. For things that matter, the counter reading+increasing should be an atomic read-modify-write. But since this is just a web counter, I guess it's sufficient if you at least keep the hazardous window very small (by not doing the write-back at the end).
      - spookthesunset 6y ago
        I mean, these were slapped onto peoples personal pages right below an animated "under construction" gif and fractal looking background images. Accuracy was not a huge concern.
      - guidoism 6y ago
        Heh yeah. It didn’t matter because there weren’t that many people hitting the pages. It was more of a thing to do that was cool because when it hit like a thousand you would be like “OMG a THOUSAND people all over the world have visited my page, what a world we live in”
        c0achmcguirk 6y ago
        And dynamic--anything dynamic--was completely insanely cool.
      - yjftsjthsd-h 6y ago
- luckylion 6y ago
  Kind of. The files need to be executable and need to have a valid Shebang. That was a common issue with Perl when developers uploaded from Windows, because the Shebang was now "/usr/bin/perl\r". ASCII mode FTP mitigated that, but was itself a terrible idea. Passing flags to Perl ("/usr/bin/perl -w") or putting env into it ("/usr/bin/env perl") usually helped. Chmod'ing over FTP isn't straight forward in most clients, so it was much more complicated for beginners to get things to run than "upload those files, go to your browser".

tyingq 6y ago

You can set up such that newly uploaded Perl, Python, etc, scripts are runnable as soon as you put them there. But, typically, you're using a template framework or other dependencies and don't want those things exposed to the web server. PHP initially worked well that way because you lumped your templates and code into one file.

shagie 6y ago

Back in days of old, I would upload a bunch of perl files into the cgi-bin directory for the server... or files that ended in .cgi into wherever in the htdocs directory. With some juggling of what the script that was the .cgi, it would have been trivial to make it launch Java and consume the data... but Java wasn't set up for that (and the startup times for a Java cgi would have been nightmarish).

Evidlo 6y ago

> To my knowledge even now you can’t just upload a bundle of .py, .rb or .jar files into a directory hosted by Apache and go. Doesn't that just depend on Apache settings? You can set up Apache to serve all requests ending in .py as CGI. As long as these scripts emit HTML the situation is the same as PHP.

darrenf 6y ago
Small nitpick: it doesn't, and never had to be, HTML that was emitted. Executables were/are responsible for headers (including `Content-type`) as well as the body.
- shagie 6y ago
  An example of this was the old, classic, counter.cgi which, when accessed would: * Read a file containing an integer * Increment the integer in memory * Emit a .gif with the new value * Write the new value back to the file
  - anyfoo 6y ago
    That's a bad order to do things, is that how it worked? There is a huge window while emitting the .gif during which other visitors may appear. At best a new visitor appearing during another visitor's "emit gif" phase does not increment the counter, at worst a visitor on a very slow line causes the cgi instance for this visitor to run for a long time and then write back a very old value to the file, making the counter run backwards. For things that matter, the counter reading+increasing should be an atomic read-modify-write. But since this is just a web counter, I guess it's sufficient if you at least keep the hazardous window very small (by not doing the write-back at the end).
    - spookthesunset 6y ago
      I mean, these were slapped onto peoples personal pages right below an animated "under construction" gif and fractal looking background images. Accuracy was not a huge concern.
    - guidoism 6y ago
      Heh yeah. It didn’t matter because there weren’t that many people hitting the pages. It was more of a thing to do that was cool because when it hit like a thousand you would be like “OMG a THOUSAND people all over the world have visited my page, what a world we live in”
      - c0achmcguirk 6y ago
        And dynamic--anything dynamic--was completely insanely cool.
    - yjftsjthsd-h 6y ago
luckylion 6y ago
Kind of. The files need to be executable and need to have a valid Shebang. That was a common issue with Perl when developers uploaded from Windows, because the Shebang was now "/usr/bin/perl\r". ASCII mode FTP mitigated that, but was itself a terrible idea. Passing flags to Perl ("/usr/bin/perl -w") or putting env into it ("/usr/bin/env perl") usually helped. Chmod'ing over FTP isn't straight forward in most clients, so it was much more complicated for beginners to get things to run than "upload those files, go to your browser".