Hacker News new | ask | show | jobs
by catchclose8919 1514 days ago
...to this day, I still can't wrap my head on how PHP even got to exist in a world where Perl was already filling the web niche just fine.

Also, if they wouldn't have made it too-weird-for-math-and-physics people, Perl would've probably filled Python's niche too.

And with that kind of resources focused on it, Perl 6 could've actually turned up into a clean nice new language that would've unified us all by also supporting nice compile-to-wasm.

</alternative-reality>
10 comments
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.

link
thesuperbigfrog 1514 days ago
>> 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/

link
thatwasunusual 1514 days ago
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.

link
cutler 1514 days ago
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.
link
wwweston 1514 days ago
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.

link
cutler 1514 days ago
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.
link
ff317 1514 days ago
+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.

link
anthk 1514 days ago
No CPAN and local::lib?
link
xorcist 1514 days ago
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.

link
nrdvana 1514 days ago
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...
link
hedora 1514 days ago
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.

link
thatwasunusual 1514 days ago
> As I understand it, PHP became popular before CGI.pm was ready.

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

link
nrdvana 1514 days ago
Was CGI.pm ever "ready"? Modern Perl releases dropped it because it was such a bad design.
link
tomc1985 1514 days ago
Pretty sure there's a way to load perl as a webserver module like PHP, then you can do that embedded stuff too
link
jerf 1514 days ago
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.

link
tomc1985 1514 days ago
> 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

link
tombert 1514 days ago
I'm speaking completely out of my ass here, but my suspicion for why PHP took over the web is largely because it was "web-first". It was free, open source, and you wrote directly on HTML pages, instead of Perl spitting out HTML via CGI.

I think ColdFusion was briefly popular for the same reason (though I think that one fell out of favor largely because it cost a ton of money).

link
dunefox 1514 days ago
If we're speaking alternative realities, I'd like to live in the one where Lisp took over instead of Java/C++...
link
incanus77 1514 days ago
I’ll tell you why it appealed to me.

I started programming web systems in ‘96, with Perl because it was on every machine and every web host. Apache mod_perl was a thing, and it was a bad thing, because it had to be restarted all the time because of memory leaks.

On the other hand, mod_php was much more solid, and additionally, at the time, MySQL was the main thing for many websites. The Perl database bindings were wordy and obtuse, but PHP was a breath of fresh air. I was able to start using it in environments in ‘99 and honestly, I’ve never looked back at Perl as a web application language, just a systems one.

That simple difference was enough to make me fully switch over, and it set me on the path of a career programmer, so I look back on that time very fondly.

One other thing: I don’t recall Perl scripts allowing C-style pre-processing inclusion the way PHP did. I worked at Linux.com around then and we used all sorts of templating and other library reuse via this inclusion.

link
toast0 1514 days ago
mod_perl was stateful and mod_php was stateless.

By that I mean, a mod_perl program was expected to change the execution state for future executions, global variables would remain, etc. There are ways to make that happen in mod_php, but it isn't the default and I don't know if they were available initially. This made it easier to share a mod_php server with many users... A mod_perl really should be suexeced per user (or something) and that's hard. Really, you want to do per user php servers too, but it wasn't obvious back then.

link
daotoad 1514 days ago
The reason was shared hosting. Most of the really good Perl options for application building used mod_perl which did not play well in shared hosting environments. If you could find a host, you were still somewhat at their mercy for getting modules installed, which was a huge pain in the neck.

Conversely, PHP was trivial to set up for safe shared hosts.

The end result was that Perl hosting was expensive and had a higher barrier to entry than PHP.

link
mekster 1514 days ago
Everyone was just starting out at pre 2000. Perl was scripting first but PHP was HTML first, as in plain HTML is still a valid PHP and it was easy for people to pick up without having have to see some weird error without the content-type "magic" line and setting the file to "777" to get it working.

But I do like its Unix feeling. Too bad no one uses it anymore and have to move on.

link
cutler 1514 days ago
Perl tended to follow rather than lead which is why it lost to its competitors - first PHP, then Ruby and Python. For example, Ruby had its own server interface - Rack - long before Tatsuhiko Miyagawa developed a version for Perl called the Perl Server Gateway Interface (PSGI) upon which Plack was built but Ruby was off to the races with Rails by then.
link
0xbadcafebee 1514 days ago
People see a tool designed for one specific purpose, assume that must be the best tool for the job, adopt it, then more people do, then it gets popular, then people adopt it just because it's popular.
link
influx 1514 days ago
As I recall, PHP just seemed blazing fast compared to Perl, and most web hosts already had it installed in Apache. Further, many web hosts didn't even allow CGI due to security issues.
link