Еще как может. У меня дважды было, что ни с того, ни с сего, в разговор в машине вдруг встревала Алиса, комментируя только что произнесенную кем-то фразу. При этом Алисы на телефоне отдельно у меня не установлено, только как голос в Яндекс.Навигаторе, причем в эти моменты был активирован другой голос (кота Гурме).
Представим, что мы едем прямо. При левостороннем движении это будет левая часть дороги. Если слева есть примыкающая дорога, для машин на ней мы - помеха справа - приоритет у нас. Если есть примыкающая дорога справа, то у нас снова приоритет, т.к. они сначала должны пропустить встречное направление по нашей дороге.
В общем, если бы при правостороннем движении у нас было бы правило помехи слева, можно было бы тоже обойтись без знаков приоритета.
бритты по сей день придерживаются варварского обычая — левостороннего движения
Мне лично левостороннее движение кажется более удобным в том числе и отсутствием необходимости на большинстве перекрестков явно определять знаками приоритет движения, т.к. основной поток всегда главный, как двигающийся справа.
Неявное изменение состояний объектов — один из источников ошибок (на Python, кстати, на эти грабли еще проще наступить, т.к. все поля класса открыты), которого лучше всё же избегать, по-моему мнению. По крайней мере важно разделять неизменные объекты и изменяемые. Когда делается гибкая архитектура с «мягкими» правилами (которые нужно соблюдать по факту использования, но не по факту определения), обязательно найдется код, который сделает это недостаточно корректно.
Не хочу критиковать архитектуру Symphony, т.к. толком с ней не знаком, но когда используется общий принцип/вызов передачи сообщений для совершенно различных операций над объектами (как, например, прокинуть какие-то параметры через универсальный изменяемый объект-событие), затрудняется еще и поиск кода, который такие изменения делает (т.к. все участники делают однотипные вызовы с примерно похожими параметрами). И одно дело, если это что-то вроде протокола шины обмена сообщениями (который сверху обернут в более высокоуровневый протокол с методами/функциями, названия которых говорят о совершаемом действии), и другое, если это основной способ общения между объектами в архитектуре приложения. Я сейчас такую проблему вижу в Django Channels — фреймворке-надстройке над Django, который добавляет в него асинхронности (слишком просто всё делать через channel.send(message), к счастью, содержимое message никто не меняет).
В общем, всё сложно, и особенно сложно сделать всё хорошо :)
Как язык Java излишне многословен по сравнению с Python, но у него чертовски хороший JIT. Python пока не догоняет по скорости. Также проекты на Java стоят дороже, так что игра стоит свеч :).
Выбор, согласен, в конце-концов остается за разработчиком — если что-то не устраивает, всегда можно сменить проект, компанию, клиентов и т.п. Рынок пока еще позволяет.
Код HttpKernel аккуратный и на первый взгляд неплох. Но потом в конце класса мы видим
private function varToString($var): string
{
if (\is_object($var)) {
return sprintf('an object of type %s', \get_class($var));
}
...
}
Стоп, что это делает в коде Http ядра и используется один единственный раз для вывода сообщения об ошибке?
Функцию явно добавили «по-быстрому» (к хорошей архитектуре она отношения не имеет), поэтому смотрим туда, где её вызывают:
$event = new GetResponseForControllerResultEvent($this, $request, $type, $response);
$this->dispatcher->dispatch(KernelEvents::VIEW, $event);
if ($event->hasResponse()) {
$response = $event->getResponse();
} else {
$msg = sprintf('The controller must return a "Symfony\Component\HttpFoundation\Response" object but it returned %s.', $this->varToString($response));
// the user may have forgotten to return something
if (null === $response) {
$msg .= ' Did you forget to add a return statement somewhere in your controller?';
}
throw new ControllerDoesNotReturnResponseException($msg, $controller, __FILE__, __LINE__ - 17);
}
И видим неявное изменение переменной $event, внутри dispatch(). Окружение мало говорит о том, что там в $event могли поменять (мы видим только то, что проверяется дальше). Более того, сам факт того, что объект «событие» подлежит изменению, также говорит о проблеме в архитектуре. Тут внутрь события засунут еще и response.
Но вижу в коде и хорошее — если response не установлен, фреймворк напомнит разработчику о том, что он нужен. Фреймворк знает, что он достаточно сложен и не очень хорошо спроектирован, чтобы у разработчика была возможность не сделать обязательное действие, но старается это исправить (ок, хотя бы так).
Но что это? Посмотрите на параметры ControllerDoesNotReturnResponseException():
// `file` index the array starting at 0, and __FILE__ starts at 1
$line = file($first['file'])[$first['line'] - 1];
$this->assertContains('call_user_func_array', $line);
Ага, автор кода брал определенную (эмпирически определенную) строчку из стэктрейса, но даже коммента не оставил, почему именно -17.
Последнее на что смотрим: коммиты автора кода "-17". 21 его коммит из 34-х (что я вижу на первой странице) привели к падению тестов в среде continuous integration проекта (уже не полезу смотреть детали).
Да, именно так, хотя и в самом языке есть неудобные (для меня) вещи, например, исторический $ в названии переменных, Java-подобные описания классов (питоновские классы очень радуют в этом плане, несмотря на нестрогость с точки зрения ООП), {} скобки (питон избаловал отсутствием синтаксического мусора).
Выбор не всегда остается за разработчиком. Бывают большие проекты с дурно пахнущим кодом, с которым приходится взаимодействовать.
Потому что это всегда разговор не только о языке, а об окружении, которое приходит (навязывается) с языком, а также о сообществе, которое языком пользуется и на этот язык влияет.
Язык определяет, какой код и как он будет написан. Также он косвенно определяет, кто будет на нём писать. Условно сравнивая с человеческими языками, можно говорить на языке из трёх матерных слов и вполне выражать всё, что нужно в повседневной жизни, но если посмотреть, какое окружение будет вокруг этого языка и кто будет на нём говорить, я бы в таком окружении жить не захотел.
Про ваш вопрос о простом блоге на Java: если говорить просто о блоге — да, это простая задача, не вижу ничего сложного (без JSP и даже сервлетов, хоть они и часть стандартного Java EE, просто есть лучшие варианты как для ядра, так и для frontend — можно даже вообще без серверных шаблонов обойтись). Если же говорить о переписывании Wordpress как о платформе, да, это задача сложная, но дело не в Java или PHP, а в сложности сделать архитектуру платформы хорошей (скопировать архитектуру Wordpress на любом языке — дурная идея).
Чтобы ответить на ваш вопрос, сравню ключевые (для меня) аспекты PHP с Java и Python (для веб я их использовал больше всего). Остановлюсь на двух: простоте входа в разработку и базовых принципах языка. Есть и другие, но эти, пожалуй, сильней всего влияют на моё субъективное восприятие языков.
Простота входа в язык и разработку. Чем проще, тем хуже, т.к. простой вход позволяет начать кодить, не особо разбираясь в разработке вообще. Как результат, большое количество чужого ужасного кода, с которым приходится работать. Это про разработку больших систем. С точки зрения быстрой разработки странички, которую никто никогда не будет поддерживать и повторно использовать, быстрый вход как раз плюс, но это не моя ниша.
PHP в этом плане слишком простой, что привело к появлению огромного количества недо-библиотек и недо-фреймворков, использование которых заставляет страдать. То же самое можно сказать о легаси-коде, которого в больших системах много.
На Java гораздо сложнее начать писать, и код на Java гораздо лучше (в среднем), чем код на PHP — я говорю про чужой код, который приходится поддерживать в больших системах. Свой код никто не мешает писать хорошо на любом языке.
Python тоже довольно прост, но, в отличие от PHP, его синтаксис изначально хорошо продуман и элегантен. Это приводит к тому, что на Python можно научиться писать быстро сразу хорошо. Да, разумеется, плохой код на Python тоже имеется (в больших системах), но его на порядки меньше. Т.е. вот если на PHP хороший код встречается как исключение, то на Python скорее наоборот — иногда встречается говнокод среди вполне годного кода. (Субъективно, без количественных метрик.)
Базовые принципы языка. Язык создается на основе каких-то принципов, также язык создается человеком (группой людей), у которго есть определенные ценности и характер, что влияет на результат. PHP был создан, как я уже писал, как удобная замена Perl и SSI. С этой ролью он отлично справлялся (после того, как я первый раз увидел PHP, я больше ни разу не писал веб на Perl и SSI, это был настоящий прорыв). Стандартную библиотеку PHP наполняли стихийно — понадобилась функция, добавили. Там было (и есть?) много близких функций с разной нотацией. Потом стали добавлять объекты и классы, потом переделали, потом… (потом я ушел на Python, так что 6-ую версию уже не застал). В итоге (с учётом п.1) на PHP каждый писал и пишет, кто во что горазд. Язык не настаивает на том, какой должен быть код, как должны быть структурированы модули (и нужны ли они вообще) и т.п. Позже эти принципы были добавлены, но они не жесткие, поэтому для простоты и быстроты от них отказываются. Дополнительные проблемы создает динамическая типизация, которая в PHP рождает много проблем на этапе отладки. Результат: много плохого кода.
Java в этом плане дает гораздо меньше свободы. Плюс статическая типизация обнаруживает много тупых ошибок на этапе компиляции, а не в продакшене. Плюс принципы ООП, которые можно нарушить, но это настолько не удобно, что для этого нужна некоторая квалификация, что снижает вероятность ошибок (см. п. 1). Java не делали, чтобы можно было быстро лабать странички, её создавали для упрощения ООП-разработки (по-сравнению с C++, у которого достаточно высокий порог входа) и дальнейшего развертывания кода.
Python был создан, чтобы програмировать снова было в кайф. Базовые принципы языка Python таковы, чтобы на нем было удобно программировать. На нём просто писать хорошо. В Python так же хорошо реализованые такие аспекты языка, как динамическая типизация (она немного строже, чем в PHP, и ошибок, с ней связанных, меньше), встроенные типы (нет с ними путаницы), функциональные возможности. Это привлекает в Python-сообщество квалифицированных программистов, которые пишут хороший код.
Использование грамотно спроектированных и разработанных фреймворков во многом спасает ситуацию. В PHP они, вероятно, тоже есть. (Автор статьи положительно пишет о Wordpress, но говорить так, можно лишь сравненивая с другими PHP-фреймворками, продуктами и библиотеками. Остальные хуже, но Wordpress — это тоже адово адище, если сравнивать с действительно нормальными, например, Django. Я соглашусь, что не вполне корректно сравнивать пакетный продукт и фреймворк для разработки. В данном случае я говорю о Wordpress как о стартовом пакете для дальнейшей разработки продукта.)
Мой собственный опыт таков, что стоило мне уйти с PHP на Python, как количество головной боли в моей жизни, рожденной чужим кодом, с которым я должен дружить, стало исчезающе малым. Прямо волшебство.
Ну а на Java, после того, как туда добавили дженерики и функциональщину, асинхронность и пр., после того как программисты наелись корявым EE и паттернами разработки, а также посмотрели, как может быть коротко, просто и ясно на других языках, на Java стало гораздо приятней писать.
Проще всего объяснить на сравнении. Но чтобы сравнение имело смысл, оно должно быть с языком, с которым человек знаком. Абстрактные «в этом языке лучше это, а в том то» не работают, пока не начнешь на нём писать. Для меня PHP был адом (до него мой бэкграунд был на C/C++, Perl и Java — для веб разработки). Но потом ко мне попал проект на Python/Django, и я офигел от того, насколько удобным и продуманным может быть язык и фреймворк, и больше на PHP не писал.
Это было в приложении под андроид, браузер запущен не был.
Еще как может. У меня дважды было, что ни с того, ни с сего, в разговор в машине вдруг встревала Алиса, комментируя только что произнесенную кем-то фразу. При этом Алисы на телефоне отдельно у меня не установлено, только как голос в Яндекс.Навигаторе, причем в эти моменты был активирован другой голос (кота Гурме).
Они смогли найти цвет, который не используется ни одним из производителей инструмента. Но что это за цвет?!! :_(
Лучшее правило, которое пока еще ни разу не подводило за 15 лет фриланса - не работать с российскими компаниями.
Это гениально, бро!
Представим, что мы едем прямо. При левостороннем движении это будет левая часть дороги. Если слева есть примыкающая дорога, для машин на ней мы - помеха справа - приоритет у нас. Если есть примыкающая дорога справа, то у нас снова приоритет, т.к. они сначала должны пропустить встречное направление по нашей дороге.
В общем, если бы при правостороннем движении у нас было бы правило помехи слева, можно было бы тоже обойтись без знаков приоритета.
Нет, там приоритет у того, кто справа.
Мне лично левостороннее движение кажется более удобным в том числе и отсутствием необходимости на большинстве перекрестков явно определять знаками приоритет движения, т.к. основной поток всегда главный, как двигающийся справа.
Не хочу критиковать архитектуру Symphony, т.к. толком с ней не знаком, но когда используется общий принцип/вызов передачи сообщений для совершенно различных операций над объектами (как, например, прокинуть какие-то параметры через универсальный изменяемый объект-событие), затрудняется еще и поиск кода, который такие изменения делает (т.к. все участники делают однотипные вызовы с примерно похожими параметрами). И одно дело, если это что-то вроде протокола шины обмена сообщениями (который сверху обернут в более высокоуровневый протокол с методами/функциями, названия которых говорят о совершаемом действии), и другое, если это основной способ общения между объектами в архитектуре приложения. Я сейчас такую проблему вижу в Django Channels — фреймворке-надстройке над Django, который добавляет в него асинхронности (слишком просто всё делать через channel.send(message), к счастью, содержимое message никто не меняет).
В общем, всё сложно, и особенно сложно сделать всё хорошо :)
Спасибо за разговор.
Да, это он.
Не хочу сказать ничего плохого про автора коммита, о котором я написал выше. Возможно, его код не так уж плох. Возможно, дело в архитектуре Symphony.
Выбор, согласен, в конце-концов остается за разработчиком — если что-то не устраивает, всегда можно сменить проект, компанию, клиентов и т.п. Рынок пока еще позволяет.
Код HttpKernel аккуратный и на первый взгляд неплох. Но потом в конце класса мы видим
Стоп, что это делает в коде Http ядра и используется один единственный раз для вывода сообщения об ошибке?
Функцию явно добавили «по-быстрому» (к хорошей архитектуре она отношения не имеет), поэтому смотрим туда, где её вызывают:
И видим неявное изменение переменной $event, внутри dispatch(). Окружение мало говорит о том, что там в $event могли поменять (мы видим только то, что проверяется дальше). Более того, сам факт того, что объект «событие» подлежит изменению, также говорит о проблеме в архитектуре. Тут внутрь события засунут еще и response.
Но вижу в коде и хорошее — если response не установлен, фреймворк напомнит разработчику о том, что он нужен. Фреймворк знает, что он достаточно сложен и не очень хорошо спроектирован, чтобы у разработчика была возможность не сделать обязательное действие, но старается это исправить (ок, хотя бы так).
Но что это? Посмотрите на параметры ControllerDoesNotReturnResponseException():
Почему именно 17? Смотрим коммит "[HttpKernel] Better exception page when the controller returns nothing", в котором это было добавлено. Есть даже тест, хорошо.
Ага, автор кода брал определенную (эмпирически определенную) строчку из стэктрейса, но даже коммента не оставил, почему именно -17.
Последнее на что смотрим: коммиты автора кода "-17". 21 его коммит из 34-х (что я вижу на первой странице) привели к падению тестов в среде continuous integration проекта (уже не полезу смотреть детали).
А как по-вашему, хороший фреймфорк Symphony?
Выбор не всегда остается за разработчиком. Бывают большие проекты с дурно пахнущим кодом, с которым приходится взаимодействовать.
HttpKernel.php посмотрел.
Язык определяет, какой код и как он будет написан. Также он косвенно определяет, кто будет на нём писать. Условно сравнивая с человеческими языками, можно говорить на языке из трёх матерных слов и вполне выражать всё, что нужно в повседневной жизни, но если посмотреть, какое окружение будет вокруг этого языка и кто будет на нём говорить, я бы в таком окружении жить не захотел.
Про ваш вопрос о простом блоге на Java: если говорить просто о блоге — да, это простая задача, не вижу ничего сложного (без JSP и даже сервлетов, хоть они и часть стандартного Java EE, просто есть лучшие варианты как для ядра, так и для frontend — можно даже вообще без серверных шаблонов обойтись). Если же говорить о переписывании Wordpress как о платформе, да, это задача сложная, но дело не в Java или PHP, а в сложности сделать архитектуру платформы хорошей (скопировать архитектуру Wordpress на любом языке — дурная идея).
PHP в этом плане слишком простой, что привело к появлению огромного количества недо-библиотек и недо-фреймворков, использование которых заставляет страдать. То же самое можно сказать о легаси-коде, которого в больших системах много.
На Java гораздо сложнее начать писать, и код на Java гораздо лучше (в среднем), чем код на PHP — я говорю про чужой код, который приходится поддерживать в больших системах. Свой код никто не мешает писать хорошо на любом языке.
Python тоже довольно прост, но, в отличие от PHP, его синтаксис изначально хорошо продуман и элегантен. Это приводит к тому, что на Python можно научиться писать быстро сразу хорошо. Да, разумеется, плохой код на Python тоже имеется (в больших системах), но его на порядки меньше. Т.е. вот если на PHP хороший код встречается как исключение, то на Python скорее наоборот — иногда встречается говнокод среди вполне годного кода. (Субъективно, без количественных метрик.)
Java в этом плане дает гораздо меньше свободы. Плюс статическая типизация обнаруживает много тупых ошибок на этапе компиляции, а не в продакшене. Плюс принципы ООП, которые можно нарушить, но это настолько не удобно, что для этого нужна некоторая квалификация, что снижает вероятность ошибок (см. п. 1). Java не делали, чтобы можно было быстро лабать странички, её создавали для упрощения ООП-разработки (по-сравнению с C++, у которого достаточно высокий порог входа) и дальнейшего развертывания кода.
Python был создан, чтобы програмировать снова было в кайф. Базовые принципы языка Python таковы, чтобы на нем было удобно программировать. На нём просто писать хорошо. В Python так же хорошо реализованые такие аспекты языка, как динамическая типизация (она немного строже, чем в PHP, и ошибок, с ней связанных, меньше), встроенные типы (нет с ними путаницы), функциональные возможности. Это привлекает в Python-сообщество квалифицированных программистов, которые пишут хороший код.
Использование грамотно спроектированных и разработанных фреймворков во многом спасает ситуацию. В PHP они, вероятно, тоже есть. (Автор статьи положительно пишет о Wordpress, но говорить так, можно лишь сравненивая с другими PHP-фреймворками, продуктами и библиотеками. Остальные хуже, но Wordpress — это тоже адово адище, если сравнивать с действительно нормальными, например, Django. Я соглашусь, что не вполне корректно сравнивать пакетный продукт и фреймворк для разработки. В данном случае я говорю о Wordpress как о стартовом пакете для дальнейшей разработки продукта.)
Мой собственный опыт таков, что стоило мне уйти с PHP на Python, как количество головной боли в моей жизни, рожденной чужим кодом, с которым я должен дружить, стало исчезающе малым. Прямо волшебство.
Ну а на Java, после того, как туда добавили дженерики и функциональщину, асинхронность и пр., после того как программисты наелись корявым EE и паттернами разработки, а также посмотрели, как может быть коротко, просто и ясно на других языках, на Java стало гораздо приятней писать.