3 ms·

> The nascent web community quickly learned that this was a bad idea, and invented technologies like PHP Well ackshually ... the technology here that was impor

> The nascent web community quickly learned that this was a bad idea, and invented technologies like PHP Well ackshually ... the technology here that was important was mod_php; PHP itself was no different to Perl in how it was run, but the design choice of mod_php as compared to mod_perl was why PHP scripts could just be dumped on the server and run fast, where you needed a small amount of thinking and magic to mod_perl working.

simonw 1y ago
Right, but mod_php was an early addition to the PHP ecosystem and quickly became the default way of deploying it - I believe the first version of the Apache module was for PHP/FI Version 2.0 in 1996: https://www.php.net/manual/phpfi2.php#module https://www.php.net/manual/phpfi2.php#module
- petesergeant 1y ago
  It was indeed, and I spent much time wailing and gnashing my teeth as a Perl programmer that nothing similar existed in Perl.
  - xnx 1y ago
    Indeed. Perl was better in many ways, but not in the one that mattered to its continued viability.
  - AdieuToLogic 1y ago
    > It was indeed, and I spent much time wailing and gnashing my teeth as a Perl programmer that nothing similar existed in Perl. mod_perl2[0] provides the ability to incorporate Perl logic within Apache httpd, if not other web servers. I believe this is functionally equivalent to the cited PHP Apache module documentation: Running PHP/FI as an Apache module is the most efficient way of using the package. Running it as a module means that the PHP/FI functionality is combined with the Apache server's functionality in a single program. 0 - https://perl.apache.org/docs/2.0/index.html https://perl.apache.org/docs/2.0/index.html
    - petesergeant 1y ago
      The key difference was that you had to adapt your Perl to work with mod_perl, where mod_php "just worked" in the same way CGIs did -- you could throw your .php scripts up over FTP and they'd benefit from mod_php being installed. This was a massive difference in practice. EDIT: I have managed to dig out slides from a talk I gave about this a million years ago with a good section that walks through history of how all this worked, CGIs, mod_perl, PSGI etc, for anyone who wants a brief history lesson: https://www.slideshare.net/slideshow/psgi-and-plack-from-first-principles-49147547/49147547#4 https://www.slideshare.net/slideshow/psgi-and-plack-from-fir...
      - pests 1y ago
        Just a story of my past. I got into web dev in the tail end of perl and cgi-bin. I remember my first couple scripts which were just copy/paste from tutorials and what not, everyone knows how it goes. It was very magical to me how this "cgi-bin" worked. There was a "script kiddy hacking tool" I think named subseven (or similar) written partially in perl that you would trick your friends into running or you'd upload on filesharing. The perl part gave you your web based C&C to mess with people or open chats or whatever. I really got into programming trying to figure out how this all worked. I soon switched over to PHP and in my inexperience never realized the deployment model was so similar. I do think this model of running the script once per request and then exiting really messed with my internal mental model of how programs and scripts worked. Once I was exposed to long running programs that could maintain state, their own internal data structures, handling individual requests in a loop, etc, was a real shock and took me awhile to conceptualize.
        simonw 1y ago
        I had the same experience! I started out with Perl and CGI, then moved to PHP. Switching to a world where the web application kept running across multiple requests took me quite a bit of effort to get used to.
        pests 1y ago
fcatalan 1y ago
At that time I was developing with a friend what later was called a Learning Management System: It had content management, assignment uploads, event calendar, grade management, real time chat, forums... It was all plain C via CGI and it was hell to work with. What almost brought us to tears the day we learned about PHP was how everything we had been painstakingly programming ourselves from scratch reading RFCs or reverse engineering HTTP was just a simple function call in PHP. No more debugging our scuffed urlencode implementation or losing a day to a stray carriage return in an HTTP header...

simonw 1y ago

Right, but mod_php was an early addition to the PHP ecosystem and quickly became the default way of deploying it - I believe the first version of the Apache module was for PHP/FI Version 2.0 in 1996: https://www.php.net/manual/phpfi2.php#module https://www.php.net/manual/phpfi2.php#module

petesergeant 1y ago
It was indeed, and I spent much time wailing and gnashing my teeth as a Perl programmer that nothing similar existed in Perl.
- xnx 1y ago
  Indeed. Perl was better in many ways, but not in the one that mattered to its continued viability.
- AdieuToLogic 1y ago
  > It was indeed, and I spent much time wailing and gnashing my teeth as a Perl programmer that nothing similar existed in Perl. mod_perl2[0] provides the ability to incorporate Perl logic within Apache httpd, if not other web servers. I believe this is functionally equivalent to the cited PHP Apache module documentation: Running PHP/FI as an Apache module is the most efficient way of using the package. Running it as a module means that the PHP/FI functionality is combined with the Apache server's functionality in a single program. 0 - https://perl.apache.org/docs/2.0/index.html https://perl.apache.org/docs/2.0/index.html
  - petesergeant 1y ago
    The key difference was that you had to adapt your Perl to work with mod_perl, where mod_php "just worked" in the same way CGIs did -- you could throw your .php scripts up over FTP and they'd benefit from mod_php being installed. This was a massive difference in practice. EDIT: I have managed to dig out slides from a talk I gave about this a million years ago with a good section that walks through history of how all this worked, CGIs, mod_perl, PSGI etc, for anyone who wants a brief history lesson: https://www.slideshare.net/slideshow/psgi-and-plack-from-first-principles-49147547/49147547#4 https://www.slideshare.net/slideshow/psgi-and-plack-from-fir...
    - pests 1y ago
      Just a story of my past. I got into web dev in the tail end of perl and cgi-bin. I remember my first couple scripts which were just copy/paste from tutorials and what not, everyone knows how it goes. It was very magical to me how this "cgi-bin" worked. There was a "script kiddy hacking tool" I think named subseven (or similar) written partially in perl that you would trick your friends into running or you'd upload on filesharing. The perl part gave you your web based C&C to mess with people or open chats or whatever. I really got into programming trying to figure out how this all worked. I soon switched over to PHP and in my inexperience never realized the deployment model was so similar. I do think this model of running the script once per request and then exiting really messed with my internal mental model of how programs and scripts worked. Once I was exposed to long running programs that could maintain state, their own internal data structures, handling individual requests in a loop, etc, was a real shock and took me awhile to conceptualize.
      - simonw 1y ago
        I had the same experience! I started out with Perl and CGI, then moved to PHP. Switching to a world where the web application kept running across multiple requests took me quite a bit of effort to get used to.
        pests 1y ago

fcatalan 1y ago

At that time I was developing with a friend what later was called a Learning Management System: It had content management, assignment uploads, event calendar, grade management, real time chat, forums... It was all plain C via CGI and it was hell to work with. What almost brought us to tears the day we learned about PHP was how everything we had been painstakingly programming ourselves from scratch reading RFCs or reverse engineering HTTP was just a simple function call in PHP. No more debugging our scuffed urlencode implementation or losing a day to a stray carriage return in an HTTP header...