![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Умные, а особенно профессиональные френды. Особенно - профессиональные там, откуда аббревиатура в заголовке. Вопрос.
Достался мне на доработку (порядка половины функциональности) LAMP-сайт. "И эти еще из лучших", то есть с кодом можно спокойно работать. Залез я туда, и задумался. А вообще есть у нас реальная альтернатива PHP для _сравнительно_ простых, но обязательно хотящих странного динамических сайтов?
Достоинства PHP (применительно к моей задаче), то есть то, чем очень не хотелось бы поступиться при поиске альтернативы:
Наиболее критичны "легкий", "странное", регексы.
Недостатки PHP, обнаруженные на моей задаче:
С неуправляемостью, конечно, жопа, но при подобающей самодисциплине (выработанной богатым опытом ходьбы по граблям, но мне, к счастью, уже данной в исходном коде - изначальный автор, как я уже говорил, из лучших) это лечится. Так что недостатки оказываются не офигительно критичными.
Сервер подразумевается все-таки выделенным, но в норме - виртуальной машиной, отсюда требования к весу. В норме Debian. То есть доставить тот или иной модуль к базовому языку подразумевается возможным.
Достался мне на доработку (порядка половины функциональности) LAMP-сайт. "И эти еще из лучших", то есть с кодом можно спокойно работать. Залез я туда, и задумался. А вообще есть у нас реальная альтернатива PHP для _сравнительно_ простых, но обязательно хотящих странного динамических сайтов?
Достоинства PHP (применительно к моей задаче), то есть то, чем очень не хотелось бы поступиться при поиске альтернативы:
- ЛЕГКИЙ (по этому параметру не проходит mod_perl, например) вместе с клиентом к мысклю и http-клиентом (надо запрашивать у стоящего на локалхосте Яндекс-сервера результаты поиска);
- простое шаблонирование;
- при этом универсальное (см. слово "странного" выше);
- простые же ручки к мысклю и к запросу HTTP и разбору ответов - разбор XML не критичен, задача позволяет сделать и более простой формат, но приветствуется, потому как XML - это уже готовый формат для неоднородных данных;
- перловые регулярные выражения (pcre годится) и отсутствие проблем с их локализацией (и вообще с локализацией строк - lc, uc, ucfirst должны работать с кириллицей);
- ну, понятно, urlencode/urldecode, мы же все-таки веб-сайт строим.
Наиболее критичны "легкий", "странное", регексы.
Недостатки PHP, обнаруженные на моей задаче:
- претензия к языку: полная неуправляемость в смысле того, что откуда взялось (чтобы выяснить, откуда у этой переменной на этой странице такое значение, приходится читать последовательно все три этажа инклудов)
- претензия к системе шаблонирования: один перевод строки - и уже не поменяешь код HTTP response. Из чего следует, что приходится вручную делить код на то, что выполняется (и может содержать рантайм-ошибки), засасывать все необходимые (или хуже того, которые _могут_ понадобиться) данные заранее (см. предыдущий пункт), и на то, что потом из засосанного уже строит страницу
С неуправляемостью, конечно, жопа, но при подобающей самодисциплине (выработанной богатым опытом ходьбы по граблям, но мне, к счастью, уже данной в исходном коде - изначальный автор, как я уже говорил, из лучших) это лечится. Так что недостатки оказываются не офигительно критичными.
Сервер подразумевается все-таки выделенным, но в норме - виртуальной машиной, отсюда требования к весу. В норме Debian. То есть доставить тот или иной модуль к базовому языку подразумевается возможным.
Tags:
no subject
http://www.haskell.org/haskellwiki/Web/Frameworks
Исходя из того, чтобы взять язык, который тебе в данный момент наиболее удобен и привычен, и выбрать для него наиболее подходящий из существующих фреймворков в данной предметной области.
no subject
... The hinge of armoring is important internal source ...
no subject
no subject
no subject
Касаемо проекта -- посчитаем время приблизительно.
Сколько занимает пиление нетривиальной похапэшной программы -- известно, но обязательно учитываем тестирование (там, где типизация делает гарантированный результат зачастую, в похапэ следует либо проверять, либо положиться на случай/память), и обязательно учитываем лёгкость внесения изменений и вообще рефакторинга (там, где опять же помогает строгая типизация), и учитываем лёгкость написания заведомо корректного кода. (понятно, что далеко не весь код корректный, но можно сравнить 10 строк кода на х-е и 5 экранов кода на похапэ и оценить лёгкость поиска ошибок при знании обоих языков.)
С другой стороны, учитывая современные туториалы, изучение х-я занимает примерно: 3 дня до уровня "я понимаю и могу исправить простые штуки", пару недель до уровня "я понимаю продакшон-код и могу почти всё исправить", месяц до уровня "я могу писать любой свой код без ограничений". Кроме того, время на изучение амортизируется в случае наличия нескольких задач, требующих знание данного языка, и есть синергетический эффект: изученное для одного из проектов скорее всего пригодится в другом.
Мой вывод: использовать х-ь однозначно. И это при том, что я -- никак не фоннат языка и его принципов.
no subject
no subject
no subject
no subject
На выходе - число (статус) и строка (сформированная страница).
Или речь идет о запросах в БД в процессе формирования страницы?
no subject
Про ввод-вывод -- это я в целом имел ввиду, но конкретно тут только "ввод" нужен, и только для разбора тела POST-запроса (а там, может, и вывод понадобится -- например, во временный файл сохранить для дальнейших разборок). И там может быть разный transfer-encoding, который удобно разбирать через iteratees -- фактически пишется один iteratee для обработки внутреннего, раскодированного потока, а далее, при нужде, его обвешивают нужными преобразователями из внешнего потока во внутренний, возможно вложенно.
no subject