Sure makes sense. I asked because I always see post about Jekyll and octopress, and such. That are basically server-less.
The problems you have with jekyll, pelican, et al is that you lose site-side search, 'related posts' (without some reasonably complex compile-side clobber), etc. etc.
Using extremely minimal PHP lets you deploy just as easily, you don't get too much of a performance hit (a hell of a lot better than wordpress, etc), you can still do search, related posts, forms, embedding, and all that.
PHP as a server-side 'clever templating' language really isn't that bad. It's only awful when used to build anything massivly complex (such as joomla! or drupal...), and that it encourages messy project design.
I only touch PHP as little as possible, and work with a legacy PHP codebase, but AFAIK, it hasn't evolved a tag to automatically HTML-escape/JSON-escape content. So, it's as good a templating language as it is a programming language: pretty terrible. I'll trade PHP for something as barebones as Python with WSGI + Jinja2 any day.
The fact is that it has been surpassed by Twig, Jinja2, Cheetah, and many other templating languages - which rather proves the point of @mercurial who you're arguing with, which is that PHP is not a great language to use for templating.
And, to be honest, I agree with him, actually. I'd be very very hard pushed to start a new project in PHP. Python+Jinja2 is a much more powerful and sane way to work.
However, as a templating language, for basic blogging stuff, if you're careful, PHP can be made to work, and, on a cheap host, may end up being easier to deploy than a technichally better system.
Just as BASH can sometimes be an easier solution to some problems than python or perl or whatever else. I'd never claim that BASH was a nice language to work in, but for very simple scripting, it can end up being an easier automation system than the alternatives.
- software cannot evolve
- the notion of sanitizing input/output has magically appeared out of thin air in the last 15 years (I'm pretty sure that Perl Mason could do that when it first came out, around the same time PHP did)
Since clearly neither is, attributing the current state of affairs to bad technical decisions early on followed by inertia is the most logical explanation.
It's like comparing Java and C#: C# has managed to regularly introduce interesting features, while Java has stagnated for a long time. Of course it's easier when you start from scratch, but especially for simple features like escaping, which I highly doubt would require major changes in architecture, there is simply no excuse.
Or a Bitcoin exchange