The problem is that it's not that simple. PHP is "embeddable" specifically for markup languages by design, and it was also designed with Apache's modularity in mind (I supppose).

Perhaps Perl could have been a good candidate too, but it missed the train by not shipping the embedding feature in default installations.

Python, or any language that depends on newlines, sucks for embedding in markups.

So, PHP wins the battle because it was created with HTML and HTTP in mind. Could have been better, much better, much-much-much better. Okay. But that doesn't matter for now :)

Not it is not! No it is not! Sorry to yell, but you're touching on one of my biggest peeves. The syntax that embeds PHP in the SGML family of markup languages was simply tacked on to an arbitrary syntax that vaguely resembles C and Perl. It was never designed.

I wrote a language that actually was designed to embed dynamic strings in static strings. It doesn't get ugly the way PHP does when you embed static strings within dynamic code within your outer static markup. It doesn't look anything like PHP.

...The best way to think of BRL is as a Scheme interpreter with an alternative syntax for strings

is where you should look for reasons of BRL's unpopularity, I think.

Can you tell us please, what is really special about BRL other than it being "Scheme with square brackets"?

The sql-repeat syntax with group-beginning? and group-ending? makes sophisticated use of result sets much more accessible than looking behind/ahead a row manually.

Hoisting a function definition you quickly made within a page out to a sitewide definition is fast and easy, so doing something quick-and-dirty doesn't lock you into dirt forever.

And don't underestimate those square brackets. They totally optimize the human "inner loop" of web development. They beat the tar out of <%, %>, and the mess of quotes, backslashes and dots that constantly trip up newbies.

If Scheme is not popular among web programmers, there must be a reason behind it, more than one reason, maybe a hundred reasons. But it's a fact. So I think if you are going to bring Scheme/Lisp into the web development market, you (I mean, not you personally, but in general) have to bring 2-3 new killer features along with HTML embedding and the language itself.

I'll try to understand BRL better, but from what you say above, those things don't seem to be really killer features. Even square brackets thing isn't a killer, I think.

That's really it - look at the dates on the sites he mentions. Wikipedia - 2002. Digg - 2004. Wordpress - 2003. FaceBook - 2004. Flickr - 2004.

The big hits of 2005 were YouTube (Python), Reddit (Python), and Twitter (Rails). Then there haven't really been many big hits since then - the ones I can think of with the most publicity are Pownce (Django), FriendFeed (Python), Justin.TV (Python), maybe Kongregate (Rails). So around 2005 there was a big shift away from PHP and towards Python/Ruby solutions.

There was a similar shift around 2000-2002 from Perl to PHP - the big hits then were LiveJournal (1998, Perl), Del.icio.us (2002, Perl), Blogger (1999, dunno), HotOrNot (2000, dunno), Craigslist (1996, Perl), EBay (1996, Perl), and IMDB (1998 or so, Perl).

I think that's the key, right there. Sites go after quick and dirty solutions, then scale and perfect from there. It's that low barrier to entry that I think draws so many developers to PHP, in spite of its problems.

Not that it doesn't suck, it just sucks so much less than ASP :p

And there are still ASP developers around, I just recently worked with a company that still writes all their stuff (websites for paying customers!) in ASP

The company I work for has about 4000 customers on an application using ASP / SQL Server 2000. If it works and it does what people want, they really don't care or know even what language it is in.

I wrote BRL, the sensible choice for something quick, based on Scheme, well before 2005.

I would also add that a lot of people chose PHP because they had been working in it since the late 90s and needed a big improvement in order to justify changing.

It isn't that people tried BRL and decided its superiority in speed of development, speed of execution, security and learnability weren't big enough. It's that people didn't try it.

The answer is that mod_php was a lot easier for a hosting provider to set up for shared hosting than mod_perl. Still is. The target user for scalable Perl and Python frameworks still seems to be someone with root access.

You learn to build a web page with embedded PHP on page three of most tutorials. I don't remember the Camel book covering that at all. If it does I didn't notice -- too busy slogging through the regexps and the hash syntax and the insane special characters and the bizarre function-declaration syntax. And I fear that, in Perl, there is no standard way to do it. There are probably 75 standards, which is helpful, but not very helpful.

If I visit any random web forum about PHP I am 97% likely to find a discussion of website development; if I visit a random Perl forum I'm just as likely to find sysadmins debating how to automate database backups, or a linguistics debate, or a game of Perl golf.

The biggest thing for me, at the time, was the ease of use of PHP/MySQL. I haven't touched Perl in nearly a decade, perhaps it got better, but even in 2000-2001 PHP made it very easy for a total newbie to build dynamic websites.

That's a fairly ridiculous claim. Perl CGI had all the momentum. It had plenty of forums. I repeat: PHP won because as the internet grew and compile-at-run CGI was no longer sufficiently scalable mod_php was more viable than mod_perl or fastcgi.