"that is what a web server does" Did. Most PHP apps don't use /some-article.php and /another-article.php with relevant PHP files under those names, that would be bizzare. There surely is A routing FRAMEWORK those days.

"One PHP file per page is also not true" ...if you're using A FRAMEWORK.

"There is also no 'default templating', I can pipe to, or make PHP calls from the command line" So what? There's still default templating outside And that's what you use unless you've got A FRAMEWORK.

Do you see a pattern here? The pattern is that you didn't read my comment, you used regexes instead. Sadly.

The PHP's default templating (stick code into templates) sucks (unusable for anything serious).

PHP's default routing (/foo/bar.php, lookup the file) sucks (you really really want one entry point for your web app.

PHP's default code layout (one PHP file per page) sucks too.

Idiomatic PHP is unusable! So you'd NEED a framework. Maybe homebrewn one. And if you're going for a framework, why not start with Django or Rails?

Every large-scale project in PHP contains an ad-hoc implementation of at least half of Django.

And every file still starts with To be fair, it's wonderful that complex PHP apps ever work. It's a complete surprise to me, I'd say they run-by-accident.

If he actually spent time reading about languages and designing his own, he would throw in function namespacing and function naming conventions and a good built-in abstraction for database access (with a strong bias against SQL injections and towards placeholders/variable binding from the day one), PHP would come out an okayish language and not an universal hate target.

There are some other blunders that he could just not make. And I'm not even dreaming about template system that makes sense now.

He didn't! Who the hell could do that if he wasn't going.

context.put(“rubyObject”, MyRubyClass.new)

Whether you would be able to call methods on it depends on whether the Snarl author did some (trivial) code magic or not, but it's certainly doable too.

Still I have no idea why would you want javascript in ruby in the first place.

And it would have syntax colouring which basic lagged in.

And languages become popular and unpopular for a reason.

For common lisp, those reasons are:

It's ancient.

Parties interested in it can't agree on anything so its development is stalled.

It claims to have a huge library which is tiny by 2009 standards, and doesn't have vital things like network i/o or unicode. Yes, implementations support those proprietarely, yet noone cares, because it's not in standard libs.

It has problems with reflection, which is doubly awful for a lisp.

CLOS is interesting, but for most uses smalltalkingly simple OO would be much more desirable.

Tool support is neliglible.

I've heard about CL, know a few things about it, and it's a failure nontheless.

Its problem isn't the unpopularity between Blub programmers; its problem is its unpopularity even between geeks. Even language geeks!

You can easily make a page with a javascript editor and immediate evaluation if you wish, and simplified api.

CL is a failure, admit it.

Everybody wants to talk and earn, nobody wants to actually work.

Do you see a problem here?

Maybe it doesn't draw pretty drawings, but otherwise it's oldnews.