Альтернативы PHP?

[filin]

Умные, а особенно профессиональные френды. Особенно - профессиональные там, откуда аббревиатура в заголовке. Вопрос.

Достался мне на доработку (порядка половины функциональности) LAMP-сайт. "И эти еще из лучших", то есть с кодом можно спокойно работать. Залез я туда, и задумался. А вообще есть у нас реальная альтернатива PHP для _сравнительно_ простых, но обязательно хотящих странного динамических сайтов?

Достоинства PHP (применительно к моей задаче), то есть то, чем очень не хотелось бы поступиться при поиске альтернативы:

1. ЛЕГКИЙ (по этому параметру не проходит mod_perl, например) вместе с клиентом к мысклю и http-клиентом (надо запрашивать у стоящего на локалхосте Яндекс-сервера результаты поиска);


2. простое шаблонирование;


3. при этом универсальное (см. слово "странного" выше);


4. простые же ручки к мысклю и к запросу HTTP и разбору ответов - разбор XML не критичен, задача позволяет сделать и более простой формат, но приветствуется, потому как XML - это уже готовый формат для неоднородных данных;


5. перловые регулярные выражения (pcre годится) и отсутствие проблем с их локализацией (и вообще с локализацией строк - lc, uc, ucfirst должны работать с кириллицей);


6. ну, понятно, urlencode/urldecode, мы же все-таки веб-сайт строим.

Наиболее критичны "легкий", "странное", регексы.

Недостатки PHP, обнаруженные на моей задаче:

• претензия к языку: полная неуправляемость в смысле того, что откуда взялось (чтобы выяснить, откуда у этой переменной на этой странице такое значение, приходится читать последовательно все три этажа инклудов)


• претензия к системе шаблонирования: один перевод строки - и уже не поменяешь код HTTP response. Из чего следует, что приходится вручную делить код на то, что выполняется (и может содержать рантайм-ошибки), засасывать все необходимые (или хуже того, которые _могут_ понадобиться) данные заранее (см. предыдущий пункт), и на то, что потом из засосанного уже строит страницу

С неуправляемостью, конечно, жопа, но при подобающей самодисциплине (выработанной богатым опытом ходьбы по граблям, но мне, к счастью, уже данной в исходном коде - изначальный автор, как я уже говорил, из лучших) это лечится. Так что недостатки оказываются не офигительно критичными.

Сервер подразумевается все-таки выделенным, но в норме - виртуальной машиной, отсюда требования к весу. В норме Debian. То есть доставить тот или иной модуль к базовому языку подразумевается возможным.

Comments

[gdsfh]

не всегда выгодно сформированную страницу пихать в строку, иногда лучше оформить её чем-то вида "генератора контента", даже несмотря на необходимость проставлять "Connection: close" и закрывать соединение. Но даже это не всего идеально: иногда лучше дать "генерирующей стороне" полный контроль над выводом тела, дав, фактически, "доступ к IO-монаде", если в терминах хаскеля.

Про ввод-вывод -- это я в целом имел ввиду, но конкретно тут только "ввод" нужен, и только для разбора тела POST-запроса (а там, может, и вывод понадобится -- например, во временный файл сохранить для дальнейших разборок). И там может быть разный transfer-encoding, который удобно разбирать через iteratees -- фактически пишется один iteratee для обработки внутреннего, раскодированного потока, а далее, при нужде, его обвешивают нужными преобразователями из внешнего потока во внутренний, возможно вложенно.