О производительности и идеологии

dev 27.02.2008 23:35

Выскажу и я свое IMHO, хоть и несколько сумбурное :)

Думаю, Parser3 больше всего страдает от отсутствия готовой идеологии применения.

Люди, которые используют тот же PHP, любят его за то, что уже есть ответы на все вопросы – платформа LAMP (LAMP – Linux, Apache, MySQL, Parser :), готовые IDE, куча готового кода, есть типовые связки.

Т.е. некие рельсы (это почти намек :) по которым можно ехать не особенно думая куда поворачивать.

Производительность – да, это важно, но я не думаю, что в ней дело. Грамотное проектирование решает большинство вопросов, если таковые возникают. Вообще, производительность – это область полная мифов и неверных предположений.

«Преждевременная оптимизация — корень всех зол». (c)

«Правило 1: Вы не знаете, где программа начнет тормозить. Узкие места возникают в неожиданных местах, поэтому не стройте догадки и изучайте скорость работы программы до тех пор, пока не удостоверитесь, что узкое место найдено».(c)

В конце-концов, если у вас такая высокая нагрузка на сервера, что парсер не справляется, то, очевидно, речь идет о серьезном проекте и ресурсы на доработку парсера, скорее всего, не являются проблемой. Если у Студии пока не было таких проблем, то уж для ресурсов начального и среднего уровня вряд ли есть реальная угроза упереться в проблему производительности именно Parser 3.

Парсер исторически возник как очень продвинутый шаблонизатор, который используется для создания front-end. А back-end'ы всегда были вещами, которые Студия делала закрытыми и ничего о них не рассказывала. IMHO, потому, что такие решения всегда писались под конкретного заказчика, и, зачастую, реализовывались вообще не как веб-приложения.

Отсюда некая недосказанность и постоянные попытки народа сделать свои "админки". Для большинства нет никакой проблемы сделать отображение информации из SQL и некий базовый интерактив (корзину, форум и т.д.) – т.е. клиентскую часть сайта.

Парсер для этого очень удобен и логичен.

Парсер не пытается быть единственно верным решением для всех задач.

Это unix-way: одна задача = один инструмент.
Мне кажется, что парсер по идеологии ближе к AWK, чем к PHP.

Если же посмотреть на реализацию, то на самом деле, много реальных инноваций и в целом свежий, прагматичный подход.
Смотрите сами:
- глобальный print
- taint (+ ограничение на один запрос к базе в конструкторе переменных)
- тип данных «таблица»
- возможность писать код в конструкторах переменных (LINQ?, не знаю, как оно правильно называется :)

...и множество различных приятных мелочей.

Проблемы начинаются тогда, когда люди пытаются сделать комплексное решение на парсере не имея прецедента, на который можно опереться.

Поэтому разработка некой базовой CMS/идеологии ее построения важнее всего остального, ИМХО. Очень интересной была библиотека pf и схема Misha v.3 Engine.

Рано или поздно решение, которое подойдет большинству все-таки появится и будет успешно развиваться.

Специализированность парсера и отсутствие необдуманных попыток закосить под язык программирования общего назначения – это, на самом деле, его сильная сторона. Жаль, что многие этого не понимают.

В общем, в первую очередь людям нужна готовая идеология применения.

---