Hacker News new | ask | show | jobs
by Arathorn 1514 days ago
It's easy; PHP is/was:

  <html><body>
  <?php echo 'Hello World'; ?> 
  </body></html>
Whilst the equivalent Perl at the time would be:

  #!/usr/local/bin/perl
  print "Content-Type: text/html\r\n\r\n";
  print "<html><body>";
  print "Hello world";
  print "</body></html>";
or possibly...

  #!/usr/local/bin/perl
  use strict;
  use warnings; 
  use CGI;
  my $q = CGI->new;
  print $q->header('text/html');
  print $q->start_html();
  print "Hello world";
  print $q->end_html();
...if you were being a bit more more fancy.

In other words, there was no standard templating; Template Toolkit eventually became a relatively defacto standard, but PHP had already won - and even then, TT had to be manually invoked rather than just going and freestyling <?php> tags everywhere in your HTML and "it just working".

In every other respect Perl is & was superior to PHP, and it's really sad to see Perl fade, despite (or because of?) its crazy flexibility and power.

5 comments

>> In other words, there was no standard templating.

I am not sure how much of a standard it was, but Perl Mason was a superb web site templating system.

Amazon and many other websites used it for years because it was flexible, high performance, and had fewer security problems compared to PHP.

http://www.masonhq.com/sites

https://masonbook.houseabsolute.com/book/

I was about to mention HTML::Mason, which was superior to many other templating solutions back then.

The biggest problem for Perl was that PHP was almost built for the web, while Perl was "just a normal programming language."

I wonder where Perl would have been if there had been a packaged and easy to install version of Apache with Perl, mod_perl, HTML::Mason etc. pre-installed in some way in late 90s.

Mod_perl was too much of a hosting liability for that to have been a possibility. You had to really watch your step with mod_perl not to expose shared memory to other processes running on the same server. Mod_perl is also much more complex than PHP or even Perl CGI. It was always considered senior Perl dev territory whereas PHP was aimed at the lower-tech DIY market.
Mason was great, but it'd have needed to be accompanied with an easy-as-adding-a-different-document-extension scheme installed by default w/ mod_perl on commodity hosting in order to have saved Perl's popularity vs PHP.

The big thing for PHP was how easy it was to go from "I've got a static HTML document that looks like what I want!" to "I've just added a tiny bit of dynamic content by sprinkling in a special tag!" on the majority of unix-based hosts. Deployment was uploading via FTP, just like it was with HTML. There's just so little conceptual distance or friction between static HTML and dynamic document/app, the pit of success is right there to fall into (granted, the peak of further success has some rocky roads out of that pit, but by then you've got momentum!).

On commodity hosting, Perl got typecast as a CGI tool instead. Which had its own power (CGI is kinda the OG serverless)... but not as easy a jumping off spot for anybody who was doing HTML.

It was only high performance if used with mod_perl and that was the problem for cheap hosts. HTML::Mason without mod_perl was a dog compared with PHP. Perl generally missed the boat with embedded templating. Catalyst, Mojolicious and Dancer eventually arrived but by then PHP had won. The Perl community also wasted a lot of energy trying to agree on a de facto way of doing OO. You had Damian Conway keeping it simple with blessed hashrefs on one side and kitchen sink OO with Moose on the other. In between were countless Moose riffs - Moo, Mouse, Mo. Not content with that, others opted for a Meta Object Protocol (MOP) for Perl but none of this stuck enough for Perl to compete with Python and Ruby which had OO built-in. These 2 factors are more or less why Perl lost mindshare when it mattered.
+1 to that. I'll add the other thing that gave PHP an edge at the time:

Installing any major work built in Perl back then was a nightmare of installing all the underlying dependency modules, often into the system directories. It didn't have a clean, standardized way to package up a script + dependencies easily, and dependency management was hellish, especially with many key modules needing platform-specific C compilation.

At that time commercial "shared" hosting was still common: many customers sharing one linux webhosting box and uploading scripts to via FTP, with no access to or control over the underlying system. If the webhost supported PHP, you could upload a php script and it Just Worked. Not so with Perl!

Perl was by far the superior language, but it just wasn't the superior experience for a beginning web developer who mostly just wanted to embed a tiny amount of CGI functionality in a static HTML page, and then upload and run it pretty much anywhere with no fuss.

No CPAN and local::lib?
That was certainly part of the convenience out of the box. But you could have done something similar with mod_perl since it had filters that could act on every page. Then embperl started to gain popularity some time in 1996, which was decidedly even more like a templating engine, and after that came Mason.

PHP really exploded in popularity when web hosting took off. It had a safe mode that made it possible to for several customers to co-exist in the same web server, without having the ability to read each other's files.

HAH, yes, "safe mode" which is really set-uid mode, meaning that if an admin restores a .php file from a backup and forgets to set the ownership, they have suddenly granted that user root access to the server. and it's called "safe mode". I hate PHP so much...
With your first example, there was no easy path to compatibly handling form requests. Web browsers really sucked back then.

As I understand it, PHP became popular before CGI.pm was ready.

> As I understand it, PHP became popular before CGI.pm was ready.

CGI.pm was created long (...) before PHP was released.

Was CGI.pm ever "ready"? Modern Perl releases dropped it because it was such a bad design.
Pretty sure there's a way to load perl as a webserver module like PHP, then you can do that embedded stuff too
Yes, but that stuff came later. It's actually the first way I used Perl on the web, but by then PHP was off to the races.

You could even get modules that would allow you to inline Python just like PHP, although the interaction between that and mandatory indentation could get a bit "interesting".

Also perhaps ironically, this style of mixing code and HTML has generally come to be regarded as an antipattern. PHP may still be able to do that, but woe unto the project that wants to write tons of code that way. But it's still the foothold PHP used to wedge its way into at least the B tier of languages.

> Also perhaps ironically, this style of mixing code and HTML has generally come to be regarded as an antipattern.

Tell that to the React world :P