Комментарии 87
Автор слишком сконцентрировался на PHP, в то время, как это применимо к программированию в общем.
Его точка зрения попахивает эгоцентризмом немного, но в общем и целом я с ним согласен в том, что решения обрастают лишней ненужной требухой очень быстро, которая не помогает, а наоборот затормаживает развитие проекта.
Его точка зрения попахивает эгоцентризмом немного, но в общем и целом я с ним согласен в том, что решения обрастают лишней ненужной требухой очень быстро, которая не помогает, а наоборот затормаживает развитие проекта.
Автор слишком многословно говорит о том, что нефиг из сверхскоростного шаблонизатора делать очередной бриллиант на канатной дороге.
Разные цели, разные ниши, разные идеологии.
ЗЫ. Не переношу Zend FW.
Разные цели, разные ниши, разные идеологии.
ЗЫ. Не переношу Zend FW.
Зря(
В смысле зря не переносишь Zend, просто ты не смог его понять(
Думаю, 12 лет теребления PHP для этого достаточно :)
Поверь, я его понял.
Но принять этот страшный кусок сплава перла, плюсов и лени не смог.
Поверь, я его понял.
Но принять этот страшный кусок сплава перла, плюсов и лени не смог.
И тут кроме кидания говна в сторону ZF я хотел бы услышать хоть один аргумент против…
*пожимая плечами*
Понимаешь, в любой профессии есть некоторый порог, после которого восприятие мира меняется с аргументально-инструментального на сенсорно-интуиционное.
Когда это происходит, становится как-то лениво отвечать в стотысячный раз портянкой из кусков кода, демонстративно сравнивающих плюсы и минусы разнообразных реализаций решений одной и той же задачи (в данной ситуации — с использованием разных инструментов одного назначения). Особенно, когда задача решается любым из этих способов, но иногда с ощущением мира в душе и за 5 минут, а в другом — с ощущением омерзения и за 25.
Я это к чему?
Если хочется, то придумай типичную задачу и реализуй её с помощью нескольких инструментов типа ZF, симфонии, уии, кисса, whatever-you-want. Ну и до кучи — с помощью современных конкурентов PHP (естественно, «конкурентов» в широком смысле слова — инструментов, ковариантных PHP на множестве околовебных ниш) типа Эрланга с Нитрогеном, Руби с Рельсами или Пайтона с приснопомянутым Джанго.
Мне заниматься этой формализацией ощущений обратно в стотысячный раз уже не хочется.
Понимаешь, в любой профессии есть некоторый порог, после которого восприятие мира меняется с аргументально-инструментального на сенсорно-интуиционное.
Когда это происходит, становится как-то лениво отвечать в стотысячный раз портянкой из кусков кода, демонстративно сравнивающих плюсы и минусы разнообразных реализаций решений одной и той же задачи (в данной ситуации — с использованием разных инструментов одного назначения). Особенно, когда задача решается любым из этих способов, но иногда с ощущением мира в душе и за 5 минут, а в другом — с ощущением омерзения и за 25.
Я это к чему?
Если хочется, то придумай типичную задачу и реализуй её с помощью нескольких инструментов типа ZF, симфонии, уии, кисса, whatever-you-want. Ну и до кучи — с помощью современных конкурентов PHP (естественно, «конкурентов» в широком смысле слова — инструментов, ковариантных PHP на множестве околовебных ниш) типа Эрланга с Нитрогеном, Руби с Рельсами или Пайтона с приснопомянутым Джанго.
Мне заниматься этой формализацией ощущений обратно в стотысячный раз уже не хочется.
Я тоже не смог его понять. Symfony (1 и 2) смог, Cake тоже. CI и ZF — нет.
Я, наверное, и сам зенд не понял. А именно, я не понял, зачем было выпускать фреймфорк, сочетающий в себе худшее из java-style oop и old-style php (<?php echo htmlspecialchars($this->_app->getTitle), ENT_NOQUOTES); ?> WTF?), когда на дворе уже наступили 2000е
/holywar
/holywar
Я поведусь на твой холивар:-)
Примеры «худшего из java-style oop»?
<?php echo htmlspecialchars($this->_app->getTitle(), ENT_NOQUOTES); ?> — в чем здесь проблема?
Примеры «худшего из java-style oop»?
<?php echo htmlspecialchars($this->_app->getTitle(), ENT_NOQUOTES); ?> — в чем здесь проблема?
Помесь ООП и глобальной функции, вызываемой к тому же с флагом. $this->_app->getTitle()->getEscaped() было бы уже гораздо лучше.
Вообще в Zend_View есть escape и правильно записывать вот так:
<?php echo $this->escape($this->headTitle()); ?>
Мне стало интересно откуда был взят код: <?php echo htmlspecialchars($this->_app->getTitle(), ENT_NOQUOTES); ?> поэтому специально сначала спросил:-)
<?php echo $this->escape($this->headTitle()); ?>
Мне стало интересно откуда был взят код: <?php echo htmlspecialchars($this->_app->getTitle(), ENT_NOQUOTES); ?> поэтому специально сначала спросил:-)
Я бы завел в качестве сущности для отдачи в шаблоны строку, которая может сама себя эскейпить различными способами. Это как один из путей, коих множество.
Суть в том, что глобальная функция с флагом плохо в любом случае, как ни крути.
Суть в том, что глобальная функция с флагом плохо в любом случае, как ни крути.
Да как-то ковырял один проектик, в нем было написано примерно таким образом.
Но <?php echo $this->escape($this->headTitle()); ?> дела особо не меняет, длина и понятность ужасает.
Я вообще от фреймворка ожидаю самоэскейпящегося <?=$title;?>, но в php это прозрачным образом нереализуемо (оборачивая строку в объект мы лишаем себя простых и понятных вещей типа if($title))
На худой конец, рельсостайл <?=h($title);?>, но это не зенд вей )
Но <?php echo $this->escape($this->headTitle()); ?> дела особо не меняет, длина и понятность ужасает.
Я вообще от фреймворка ожидаю самоэскейпящегося <?=$title;?>, но в php это прозрачным образом нереализуемо (оборачивая строку в объект мы лишаем себя простых и понятных вещей типа if($title))
На худой конец, рельсостайл <?=h($title);?>, но это не зенд вей )
Вы тоже из тех, кто не разобрался
Эта конструкция
даёт
Эскейпленный, естественно
Эта конструкция
<?=$this->headTitle();?>даёт
<title>...</title>Эскейпленный, естественно
Есть __toString. Для самоэскейпинга прозрачно.
А if ($title) как раз не прозрачно, имхо — нужно знать правила приведения строки к булю и понимать что условие сработает если title равно '0' (да ещй написать в user guide «заголовок поста должен быть непустым, не более 100 символов, и не символ 0»). Предпочитаю явное сравнение (empty(), увы, тоже не очевидна).
А if ($title) как раз не прозрачно, имхо — нужно знать правила приведения строки к булю и понимать что условие сработает если title равно '0' (да ещй написать в user guide «заголовок поста должен быть непустым, не более 100 символов, и не символ 0»). Предпочитаю явное сравнение (empty(), увы, тоже не очевидна).
мы, наверное, друг друга не поняли. проблема с __toString в том, что если оборачивать выводимые переменные в объект, то… объект всегда приводится к true, нету в php контроля приведения к bool.
писать вокруг этого свои конструкции if($title->toBool()) — тоже приятного мало.
может я где-то чего-то недопонял, но сделать вменяемый самоэскейпинг, не ломающий никаких распространенных конструкций я в свое время не осилил.
P.S: также немало попоболи мне доставила реализация массивных интерфейсов. Казалось бы, объект себя ведет как массив, реализует все как массив,крякает как массив, ан нет, is_array($obj) == false :)
писать вокруг этого свои конструкции if($title->toBool()) — тоже приятного мало.
может я где-то чего-то недопонял, но сделать вменяемый самоэскейпинг, не ломающий никаких распространенных конструкций я в свое время не осилил.
P.S: также немало попоболи мне доставила реализация массивных интерфейсов. Казалось бы, объект себя ведет как массив, реализует все как массив,
В ZF это выглядит так: <?php echo $this->headTitle() ?>,
а с директивой short_open_tags=On так:<?= $this->headTitle() ?>
а с директивой short_open_tags=On так:<?= $this->headTitle() ?>
ага. давайте эскейпить символы прямо в контроллерах.
А не
<?php echo $this->headTitle($title) ?>?
Поддерживаю, после того, как посмотрел на ZF 2, мне проще на Java веб-приложение создать.
Его точка зрения попахивает эгоцентризмом немного, но в общем и целом я с ним согласен в том, что решения обрастают лишней ненужной требухой очень быстро, которая не помогает, а наоборот затормаживает развитие проекта.
Приведите пример, если не сложно!
НЛО прилетело и опубликовало эту надпись здесь
«Я думаю, что PHP достаточно сложен» — в оригинале «I think PHP is complicated enough». Возможно здесь я неправильно перевел. Без контекста тяжело уловить суть. Я думаю, что автор имел ввиду нечто другое.
Евгений, хорош уже всех не согласных с Вами к низшим существам приравнивать. Вы ничуть ни лучше, носитесь со своими паттернами, как сектант. Автор потрудился изложить свое видение, а Вы только огрызаетесь в комментариях.
Я думаю, что истина, как всегда где-то посредине.
Евгений, хорош уже всех не согласных с Вами к низшим существам приравнивать. Вы ничуть ни лучше, носитесь со своими паттернами, как сектант. Автор потрудился изложить свое видение, а Вы только огрызаетесь в комментариях.
Я думаю, что истина, как всегда где-то посредине.
Кстати, в блоге автора есть ссылки на статьи, критикующие манифест. Можете почитать. Там люди удивительно хорошо, в отличии от Вас, могут излагать свои мысли.
Буквально недавно хотел попробовать один из микрофреймворков и остановился на KissMVC.
Да, приятно. Да, заманчиво. И фрейм хорош, как по мне.
Но после того, как я стал замечать, что вручную пытаюсь написать реализации некоторых вещей, которые уже встроены в CI (не реклама, но предпочтение), я бросил идею о микрофреймворках. На мой взгляд минимализм тоже должен быть оправдан.
Хотя бесконечным return array( внутри Yii я тоже не рад и очевидности коду, мне кажется, это не придает.
Да, приятно. Да, заманчиво. И фрейм хорош, как по мне.
Но после того, как я стал замечать, что вручную пытаюсь написать реализации некоторых вещей, которые уже встроены в CI (не реклама, но предпочтение), я бросил идею о микрофреймворках. На мой взгляд минимализм тоже должен быть оправдан.
Хотя бесконечным return array( внутри Yii я тоже не рад и очевидности коду, мне кажется, это не придает.
Мой мозг орет:
FUCK.
THAT.
SHIT.
(не смог подобрать лучших слов – прим. переводчика)
НАХУЙ.
ЭТО.
ДЕРЬМО.
(хотя точки после каждого слова смотрятся странно)
Раньше (может годик назад) был прикольный проект именно такого плана phpKISS (Keep It Simple Stupid), однако сейчас гугл предлагает создать новый проект с этим именем, видимо проект умер. Не знаю, как проверить, вот этот проект — это он же?
Мой мозг орет:
FUCK.
THAT.
SHIT.
ЕБИСЬ
ОНО
КОНЁМ
— на мой взгляд, самый близкий по смыслу аналог.
А мне наоборот нравится углубляться в изучение сложных библиотек и фремворком таких как Doctrine и Symfony.
Полностью ЗА!
Я, например, тоже из тех, кто недолюбливает слишком жирное абстрагирование от предметной области. У меня кровоточат глаза, когда мне приходится иметь дело с какой-нибудь джавой или там PHP+Symfony — куда ни глянь, везде мельтешат какие-то итераторы, фабрики, интерфейсы, ивенты, а что фактически делает этот код — остаётся загадкой. Тот случай, когда за деревьями не разглядеть леса.
Но с другой стороны, безо всего этого наваристого дизайна становится довольно уныло, если не сказать абсолютно невозможно, в условиях, приравненных к энтерпрайзу, когда одна система написана полусотней людей на пяти языках и вагоне 3d party компонентов.
Но с другой стороны, безо всего этого наваристого дизайна становится довольно уныло, если не сказать абсолютно невозможно, в условиях, приравненных к энтерпрайзу, когда одна система написана полусотней людей на пяти языках и вагоне 3d party компонентов.
Мне печально слышать, что у php-разработчика являются загадкой «библейские» паттерны в стиле итераторов и фабрик(
Они просто нужны далеко не на каждом шагу
Не все же php разработчики такие.
К сожалению не все знакомы с паттернами.
Это не зависит от языка программирования.
К сожалению не все знакомы с паттернами.
Это не зависит от языка программирования.
Я вот на Silex и Symfony 2 для маленьких — средних и средних — больших соответственно, подсел. Удобно тем, что микрофреймворк основан на компонентах макрофреймворка, таким образом что-то можно перенести, похожие подходи, схожий интерфейс.
Баян! Об этом манифесте я читал в январе, но это не главное…
Вот мое мнение по этому поводу:
Любой, кто воспринимает этот манифест, как руководство к действию, НИКОГДА не написал ни одного серьезного большого проекта! Микрофреймворк хорош для микропроекта, выполняющего одну, две функции, но когда проект разрастается любой адекватный разработчик понимает, что он выходит за рамки микрофремворка, и идет дальше. Есть люди, которые не хотят идти дальше и пишут костыли, другие переделывают архитектуру.
Вот мое мнение по этому поводу:
Любой, кто воспринимает этот манифест, как руководство к действию, НИКОГДА не написал ни одного серьезного большого проекта! Микрофреймворк хорош для микропроекта, выполняющего одну, две функции, но когда проект разрастается любой адекватный разработчик понимает, что он выходит за рамки микрофремворка, и идет дальше. Есть люди, которые не хотят идти дальше и пишут костыли, другие переделывают архитектуру.
Кстати я смотрел Silex и первая мысль, которая у меня возникла: этот микрофремворк слишком избыточен для разработки простого проекта: DQL и Twig лишние — они скорее замедлят разработку, потому что разработчику придется учить язык для доступа к данным и язык шаблонов, вместо того чтобы делать работу.
Никто не заставляет их использовать — в своё время я обошёлся простыми DAO классами и json в качестве view.
Язык, который надо учить, только один пожалуй — английский. Никаких проблем далее не возникает при хорошей IDE и автодокументации. Вообще в twig и вовсе нечего учить, там почти все возможные стандартные примеры выложены на оф.сайте
Это всё лапша для бедных, нужно меряться не количеством НАПИСАННОГО кода фреймворка, а количеством кода который НУЖНО НАПИСАТЬ.
вместо всего описанного куска кода на ZF в реальности нужно написать
zf create project ProjectName
после этого клепаешь контроллеры, модели и виьхи, чей вес будет обычно значительно меньше кода на микрофреймворках, а при той же функциональности и качестве отличия будут и вовсе на порядок.
Вместо манифеста показали бы лучше готовый проект с таким подходом, а попробовал я попробовал разные подходы и возненавидел маленькие фреймворки.
вместо всего описанного куска кода на ZF в реальности нужно написать
zf create project ProjectName
после этого клепаешь контроллеры, модели и виьхи, чей вес будет обычно значительно меньше кода на микрофреймворках, а при той же функциональности и качестве отличия будут и вовсе на порядок.
Вместо манифеста показали бы лучше готовый проект с таким подходом, а попробовал я попробовал разные подходы и возненавидел маленькие фреймворки.
Да ну бросьте. Уж только не ZF хвалить в за кол-во кода требуемого от разработчика. Все его конкуренты, исключая симфонию, имеют в 2, ато и в 3 раза более компкатный синтаксис.
Это никак не уменьшает его крутости как готового ко всему фреймворка, но простота вызовов и краткость кода — не его конёк точно.
Это никак не уменьшает его крутости как готового ко всему фреймворка, но простота вызовов и краткость кода — не его конёк точно.
Как-то, по-моему, некоторые вещи друг другу противоречат. Чтобы самому писать кода меньше надо управлять большим количеством чужого кода. И чтобы маленькие вещи без переписывания хорошо работали вместе нужно писать для них обвязку.
Ну вот почему-то некоторые думают, что чем больше кода, тем быстрее он работает. А это, на самом деле, не так. И микрофреймворки не должны отличаться высокой производительностью в задачах, крупнее hello world. Пример: роутинг. Есть набор шаблонов URL (регулярных выражений), которые привязаны к методам. Фреймворк проверяет, какому из шаблонов соответствует введённый URL, последовательно перебирая каждый из шаблонов и проверяя, соответствует ли ему URL или нет. При разрастании проекта таких шаблонов будет становиться всё больше и больше и время, нужное на роутинг, будет увеличиваться. Потому в идеале нужно сделать подход, принятый в утилите lex: составить конечный автомат, соответствующий всем шаблонам сразу, и каждому конечному состоянию приписать метод, который нужно дёргать при совпадении. Потом этот недетерминированный конечный автомат преобразуется в детерминированный и в итоге весь роутинг делается за один тривиальный проход по URL'у. Конечно, в PHP всё быстрее будет проверить несколько регулярок. А вот, например, в Java очень даже есть смысл сделать подобную оптимизацию. В случае с Java код фреймворка можно сделать ещё жирнее: сгенерировать байт-код. Так код фреймворка «жирнеет», время на запуск увеличивается. Зато всё летает. При этом, клиентский код никак не меняется — как был контроллер с аннотированными методами, так он и остался.
Я понимаю, что роутинг вряд ли может стать узким местом. Это всего лишь наглядный пример. Тем более, что если все компоненты фреймворка писать в две строчки, не заботясь о производительности, то рано или поздно вроде бы незначительные накладные расходы в каждой отдельно взятой части выльются в тормоза всей системы в целом.
Я понимаю, что роутинг вряд ли может стать узким местом. Это всего лишь наглядный пример. Тем более, что если все компоненты фреймворка писать в две строчки, не заботясь о производительности, то рано или поздно вроде бы незначительные накладные расходы в каждой отдельно взятой части выльются в тормоза всей системы в целом.
Какой-то корявый у вас роутинг. Меньше кода — ВСЕГДА лучше производительность. Только в асме бывают исключения.
Неужто? O_o А я и не знал. Ну конечно же, все эти яйцеголовые парни пишут распределённую сортировку слиянием чисто ради выпендрёжа — нет бы написать простой пузырёк, который мало того, что простой и понятный, так ещё и быстрый, потому что всего три строчки. Ну или там все эти многочисленные СУБД — нет, чтобы как все нормальные люди просто искать по списку — они нагородили какие-то B-деревья, R-деревья, планы запросов. Конечно же, там всё внутри настолько жирное, что адски тормозит. Ну все мы знаем, что производительность сайтов сильно в БД упирается. Вон, какие-то жалкие 20 запросов на отрисовку страницы сделают, страница уже целую секунду рендерится. А оно вот, оказывается, почему так.
НЛО прилетело и опубликовало эту надпись здесь
Вы не путайте математическую сложность алгоритмов с количеством строчек кода в их реализации.
При достаточно большом размере задачи асимптотическая сложность начнёт себя проявлять и алгоритм с меньшей асимптотической сложностью даст большую производительность на практике. Тем более, не всегда небольшая асимптотическая сложность даётся ценой накладных расходов на реализацию. Бывают ещё оффлайн-алгоритмы, которые предполагают постоянные или редко изменяющиеся данные на входе. Тогда, ценой некоторых расходов на препроцессинг, получаем быстро работающий (в том числе и практически) алгоритм. То, что я описал для роутинга — классический пример. Имеем задержку при старте (а преобразование НКА в ДКА — это задача со сложностью в худшем случае O(exp(n)), где n — число состояние, но на самом деле, это надо очень постараться сделать такую плохую регулярную грамматику), но при этом полученный автомат будет работатать со скоростью O(n), где n — размер URL. И практическая скорость будет очень высокой, т.к. если сгенерировать байт-код, выйдет простой цикл и несколько switch'ей.
Так вот обьясните мне, почему я должен выбрать фреймворк на стопицот мегабайт кривого кода, если роутинг решается в одну строчку регуляркой? Мы говорим про языки высокого уровня, поэтому нас не волнует вес бинарного интерпретатора, в котором уже реализовано всё что требуется для регулярок.
Одна строчка против тысячи классов всегда лучше. И оправдания тысяче классов нет.
Одна строчка против тысячи классов всегда лучше. И оправдания тысяче классов нет.
Ну хотя бы потому, что регулярка — это нифига не регулярка, а разбухший монстр. Регулярки в Perl, PHP и много ещё где способны работать с надмножеством регулярных грамматик. Естественно, при этом асимптотическая сложность работы с такими регулярками будет уже не O(n). Разумеется, в чём-то вроде PHP или Perl смысла нет писать свой код для реализации конечных автоматов. А вот в случае с Java и C# очень даже есть, потому что они хоть и высокоуровневые, посимвольного разбора строк не боятся. Кстати, движки регулярных выражений в этих языках написаны на них же самих.
В PHP у регулярок есть ещё одна проблема — приходится сам текст регулярок парсить каждый раз. Но всё равно, в случае с PHP регулярки использовать лучше, чем городить посимвольное распознавание. Попробую позже привести пример того, что на PHP реализуется бОльшим объёмом кода, но при этом быстрее работает.
В PHP у регулярок есть ещё одна проблема — приходится сам текст регулярок парсить каждый раз. Но всё равно, в случае с PHP регулярки использовать лучше, чем городить посимвольное распознавание. Попробую позже привести пример того, что на PHP реализуется бОльшим объёмом кода, но при этом быстрее работает.
Вот пример, где на PHP кода больше, но всё равно, он получается и на практике быстрее: кэширование. memcache мало того, что заставляет писать лишний код, так ещё и сам по себе гора кода, которая может глючить.
Давайте экономить время — и позволим фреймворкам работать за нас.
CakePHP save the world!
CakePHP save the world!
Степень сложности отладки растет пропорционально степени сложности Framework-a.
Большинство задач в веб не сложнее калькулятора.
Как сказал выше один человек
«За деревьями леса не видно.»
Мы превратили PHP из языка написания веб страничек в язык написания прикладного ПО.
Я солидарен с автором.
Большинство задач в веб не сложнее калькулятора.
Как сказал выше один человек
«За деревьями леса не видно.»
Мы превратили PHP из языка написания веб страничек в язык написания прикладного ПО.
Я солидарен с автором.
ЗЫ.
Я хочу быть Грегом Джинном.
Я хочу быть Грегом Джинном.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
The MicroPHP Manifesto