Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 165
или «Мне понравился язык Z, и теперь мне кажется открылась сама Истина, поэтому я нагуглил аргументов против языка X ну и Y заодно»
January 23rd, 2014
Устаревшая статья об устаревании PHP
А что с тех пор принципиально изменилось?
Можно спорить с тем, что язык устарел и непригоден, демонстрируя отличные кейсы его использования, но аргументы в статье сохраняют актуальность — новые версии не решают практически ничего из перечисленного.
Можно спорить с тем, что язык устарел и непригоден, демонстрируя отличные кейсы его использования, но аргументы в статье сохраняют актуальность — новые версии не решают практически ничего из перечисленного.
Он медленный, неуклюжий
По совокупности скорости/стоимости разработки и производительности PHP явно не среди отстающих
Если вы делаете CMS в проекте, которому нужны 100 серверов, вам придётся деплоить CMS целиком на каждый из 100 серверов.
А в других языках не надо деплоить код и зависимости? Composer и билд-системы в помощь
Какие инновации в мире PHP существуют сегодня?
Инновации ради инноваций? Что есть у других языков, чего нет в PHP?
Люди добавляют pthreads, когда в языке нет инструментов для работы с параллелизмом. Для контраста взгляните на Clojure.
Люди как раз и добавляют эти самые инструменты (в виде расширений). Для параллелизма не нужно какого-то особенного синтаксиса в языке.
Сложная система кэширования кода у Symfony.
Сложная — не значит медленная. Ну и если не нравится Symfony, то есть любые другие фреймворки и, благодаря стандартам и их модульности, можно собрать свой собственный фреймворк из компонентов той же Symfony.
В комментарии добавляют аннотации – инструкции, контролирующие выполнение программы.
Тут согласен, аннотации в комментариях неудобны.
Список изменений и исправлений, которые необходимо сделать из-за длинной истории противоречивой разработки.
Разбухшее управление памятью.
Уже не особо актуально, спустя 1.5 года и в свете phpng
Ритуальное программирование – куча ненужных инструкций, без преимуществ вроде проверки на этапе компиляции.
Абстракции, родительские классы, интерфейсы и все прочее нужны не только для проверки во время компиляции на возможные опечатки, но и для универсализации и струкрурирования кода, ведь его еще потом поддерживать нужно. Ну и скоро будет
declare(strict_types=1); для жаждущих строгой типизации.Любовь к сложности ради сложности.
При чем тут язык, если автор сетует на сложность конкретного проекта Doctrine ORM (причем ссылка ведет на пост 2012го года)?
Никаких настроек для управления и конфигурирования.
Аргумент 2010го года. С тех пор появился Composer.
Обилие обезьяньих патчей (подмены методов и значений атрибутов классов программы во время ее выполнения). traits похожи на обезьяньи патчи в Ruby, но с traits ещё сложнее работать, а также отслеживать и отлаживать их.
Как правильно использовать трейты и зачем они нужны
Бесконечное множество функций, введённых для удобства.
Выше была жалоба на отсутствие инструментов, теперь наоборот.
Вместо этого Рамус Лердорф говорит вещи навроде
PHP разрабатывается не одним человеком, а сообществом и все решения принимаются путем голосования. Одна цитата без контекста ничего не значит.
Недостаток глубокого видения у лидеров команды разработчиков PHP ведёт к уродливым проявлениям, в частности, к отсутствию наставлений для начинающих программистов о том, как писать на PHP хороший код.
У PHP самое большое сообщество, обучающих статей в разы больше, чем о других языках. Например, PHP. Правильный путь.
Ну и впечатление от самой статьи такое же как и у artyfarty: «Тут я не смог разобраться с библиотекой, там не понял зачем этот функционал в языке. PHP плохой.»
По совокупности скорости/стоимости разработки и производительности PHP явно не среди отстающих
Вот к этому хотелось бы увидеть обоснование, при этом распространив «разработку» и на «поддержку». Несомненно, когда PHP был на стадии развития «крутой шаблонизатор с батарейками, который уже может ого-го!», а типичные требования к сайтам были невысоки, эта фраза вряд ли вызывала сомнения. Но с тех пор мир радикально изменился, требования взлетели до небес, типичная сложность проекта в принципе изменила подход к созданию сайтов, использование PHP как шаблонизатора выглядит не просто дурным тоном, а предупреждающим сигналом «тяжёлое наследие»… У языка с богатыми возможностями «прострелить себе ногу», не самым высоким средним уровнем квалификации программистов по отрасли… Приведённое выше утверждение выглядит очень сомнительным. «Стандарт де-факто» — не значит «хорошие показатели».
По поводу деплоя — я согласен. В системах «на 100500 хостов», деплой не сводится к простым стандартным инструментам, а сам по себе является параллельным сложным проектом. Это плохой аргумент против любого языка.
Инновации ради инноваций? Что есть у других языков, чего нет в PHP?
Вопрос звучит как риторический, но всё же отвечу: чего нет в PHP и что очень бы хотелось в нём видеть, периодически вызывает очень жаркие и болезненные дискуссии в том числе и на хабре (вот habrahabr.ru/post/184142, например). Многие возможности числятся ожидаемыми уж за десяток лет.
Что есть в других языках? Ну вот например краткий синтаксис создания генераторов и последовательностей/множеств в питоне, значительно облегчающий восприятие кода. Или компактные лямбды и замыкания в стиле "|x| x * y" — сравнить с принятым в PHP громоздким подходом, где «inline» функция растягивается на 3 строки только потому что иначе оно совсем уж нечитаемо?
Из того же питона модули, с возможностью их перезагрузки без перезапуска процесса (хотя это конечно не эксклюзив питона, многие языки могут), возможность перехватывать ошибки синтаксиса программно, а не ловить внезапно мистически падающий из-за кривой функции целый интерпретатор (Да, PHP тоже может работать в режиме демона/TrueFastCGI, и от этого подобные падения вдвойне неприятны).
Многие фичи в языке за последние годы вообще появлялись через «не хочу», когда сообщество их буквально вымаливало.
Уже не особо актуально, спустя 1.5 года и в свете phpng
phpng закрывает далеко не все вопросы, особенно связанные с наследием. Наверно это самый существенный контраргумент, но это до сих пор «журавль в небе», который в широкий продакшн пойдёт через годы.
Как правильно использовать трейты и зачем они нужны
Дело не в самих трейтах и не только в трейтах. PHP действительно громоздкий и местами неуклюжий язык. Очень многое можно делать проще и компактней, если есть соответствующие средства. Соответствующих средств — нет и не скоро предвидится. Язык проникнут этой громоздкостью, её наследуют ведущие фреймворки и добавляют от себя. «Громоздко» или «сложно» — действительно не значит «медленно», но вполне значит «неудобно» и «много лишних телодвижений», а значит разработка переусложнена, много времени и сил тратится впустую, ухудшая те самые показатели из первого пункта. Может это и не так заметно, когда работаешь только с PHP, но по настоящему осознаётся только при работе с другими языками.
Бесконечное множество функций, введённых для удобства.
Я думаю автор вкладывал в эту фразу максимум ядовитого сарказма, поскольку функция http_build_query — как раз один из вопиющих примеров нелогичностей, громоздкостей и отсутствия системного подхода даже в рамках одной функции.
Одна цитата без контекста ничего не значит.
Это не одна цитата, Лердорф периодически отжигает что-то в этом же духе.
I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say «Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.» I’ll just restart Apache every 10 requests.
Сообщество разработчиков — это конечно хорошо, но факт остаётся фактом, php почти ровесник многих языков, но очень сильно им уступает. В первую очередь, потому что он не создавался как язык программирования, а рос вокруг функций шаблонизатора, которые в конце концов перерос, но вот что с этим действительно можно сделать — его автор так и не решил для себя этот вопрос. Язык как поднялся из хаоса «добавим то, прикрутим это — вроде работает, да и ладно», так в этом режиме и остался. Чего только стоит история с однажды поломанным и в течение нескольких версий не исправленным htmlspecialchars. Коллектив разработчиков? Он не выручает PHP, поскольку внутри он устроен так же, как и снаружи — как нагромождение хаоса.
Вот phpng с его «революционностями» действительно выглядит как надежда на светлое будущее. Но когда это всё будет? И когда это принесёт свои плоды? Несомненно, хоронить PHP несколько преждевременно — он завоевал мир и достаточно прочно обосновался при всех своих недостатках, с небосклона Web сойдёт ещё не скоро и хоронить его будут ещё долго и упорно. Но если дальше что-то существенно не поменяется в мире PHP, место ему только в музее — мир всё сложнее и требовательнее.
Вот к этому хотелось бы увидеть обоснование, при этом распространив «разработку» и на «поддержку». Несомненно, когда PHP был на стадии развития «крутой шаблонизатор с батарейками, который уже может ого-го!», а типичные требования к сайтам были невысоки, эта фраза вряд ли вызывала сомнения. Но с тех пор мир радикально изменился, требования взлетели до небес, типичная сложность проекта в принципе изменила подход к созданию сайтов, использование PHP как шаблонизатора выглядит не просто дурным тоном, а предупреждающим сигналом «тяжёлое наследие»… У языка с богатыми возможностями «прострелить себе ногу», не самым высоким средним уровнем квалификации программистов по отрасли… Приведённое выше утверждение выглядит очень сомнительным. «Стандарт де-факто» — не значит «хорошие показатели».
По поводу деплоя — я согласен. В системах «на 100500 хостов», деплой не сводится к простым стандартным инструментам, а сам по себе является параллельным сложным проектом. Это плохой аргумент против любого языка.
Инновации ради инноваций? Что есть у других языков, чего нет в PHP?
Вопрос звучит как риторический, но всё же отвечу: чего нет в PHP и что очень бы хотелось в нём видеть, периодически вызывает очень жаркие и болезненные дискуссии в том числе и на хабре (вот habrahabr.ru/post/184142, например). Многие возможности числятся ожидаемыми уж за десяток лет.
Что есть в других языках? Ну вот например краткий синтаксис создания генераторов и последовательностей/множеств в питоне, значительно облегчающий восприятие кода. Или компактные лямбды и замыкания в стиле "|x| x * y" — сравнить с принятым в PHP громоздким подходом, где «inline» функция растягивается на 3 строки только потому что иначе оно совсем уж нечитаемо?
Из того же питона модули, с возможностью их перезагрузки без перезапуска процесса (хотя это конечно не эксклюзив питона, многие языки могут), возможность перехватывать ошибки синтаксиса программно, а не ловить внезапно мистически падающий из-за кривой функции целый интерпретатор (Да, PHP тоже может работать в режиме демона/TrueFastCGI, и от этого подобные падения вдвойне неприятны).
Многие фичи в языке за последние годы вообще появлялись через «не хочу», когда сообщество их буквально вымаливало.
Уже не особо актуально, спустя 1.5 года и в свете phpng
phpng закрывает далеко не все вопросы, особенно связанные с наследием. Наверно это самый существенный контраргумент, но это до сих пор «журавль в небе», который в широкий продакшн пойдёт через годы.
Как правильно использовать трейты и зачем они нужны
Дело не в самих трейтах и не только в трейтах. PHP действительно громоздкий и местами неуклюжий язык. Очень многое можно делать проще и компактней, если есть соответствующие средства. Соответствующих средств — нет и не скоро предвидится. Язык проникнут этой громоздкостью, её наследуют ведущие фреймворки и добавляют от себя. «Громоздко» или «сложно» — действительно не значит «медленно», но вполне значит «неудобно» и «много лишних телодвижений», а значит разработка переусложнена, много времени и сил тратится впустую, ухудшая те самые показатели из первого пункта. Может это и не так заметно, когда работаешь только с PHP, но по настоящему осознаётся только при работе с другими языками.
Бесконечное множество функций, введённых для удобства.
Я думаю автор вкладывал в эту фразу максимум ядовитого сарказма, поскольку функция http_build_query — как раз один из вопиющих примеров нелогичностей, громоздкостей и отсутствия системного подхода даже в рамках одной функции.
Одна цитата без контекста ничего не значит.
Это не одна цитата, Лердорф периодически отжигает что-то в этом же духе.
I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say «Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.» I’ll just restart Apache every 10 requests.
Сообщество разработчиков — это конечно хорошо, но факт остаётся фактом, php почти ровесник многих языков, но очень сильно им уступает. В первую очередь, потому что он не создавался как язык программирования, а рос вокруг функций шаблонизатора, которые в конце концов перерос, но вот что с этим действительно можно сделать — его автор так и не решил для себя этот вопрос. Язык как поднялся из хаоса «добавим то, прикрутим это — вроде работает, да и ладно», так в этом режиме и остался. Чего только стоит история с однажды поломанным и в течение нескольких версий не исправленным htmlspecialchars. Коллектив разработчиков? Он не выручает PHP, поскольку внутри он устроен так же, как и снаружи — как нагромождение хаоса.
Вот phpng с его «революционностями» действительно выглядит как надежда на светлое будущее. Но когда это всё будет? И когда это принесёт свои плоды? Несомненно, хоронить PHP несколько преждевременно — он завоевал мир и достаточно прочно обосновался при всех своих недостатках, с небосклона Web сойдёт ещё не скоро и хоронить его будут ещё долго и упорно. Но если дальше что-то существенно не поменяется в мире PHP, место ему только в музее — мир всё сложнее и требовательнее.
А чем php удобнее python для маленьких проектов? Легче найти дешевых программеров и дешевый хостинг? Куча готового кода на все вебслучаи жизни?
А нельзя ли развить мысль более аргументированно с примерами?
Т.е. я могу установить отдельно только пакет кеширования из Django (он ведь там есть) и использовать вместе, например, с каким-нибудь самописным решением? А то я вижу в репозитории (https://github.com/django/django/tree/master/django/core/cache) всё в куче, как делали в PHP года 2-3 назад. Например кеш в симфони (точнее доктрины): github.com/doctrine/cache
Смысл Симфони в том, что он одновременно и модульный до безобразия, и исходники там практически идеальные, и при этом имеет стандартное приложение (тоже отдельный компонент), который объединяет все эти компоненты в одно единое, и это не микрофреймворк.
Если что-либо приходится писать, какое-то легковесное приложение — проще всего вместо всего фрейма взять пару-тройку компонентов: Twig (шаблонизатор), HttpFoundation (удобная работа с Request -> Response), Doctrine Cache и просто собрать нужное. При этом можно быть на 99.9% уверенным, что там нет никаких ошибок. Например такие фреймворки, как Laravel, Lumen, Slim процентов на 30-50 состоят из его компонентов.
Ну и к тому же оно ставится одной строчкой: `composer install symfony/finder 2.5.*` (поставить в проект компонент работы с поиском файлов в ФС версии 2.5).
Если что-либо приходится писать, какое-то легковесное приложение — проще всего вместо всего фрейма взять пару-тройку компонентов: Twig (шаблонизатор), HttpFoundation (удобная работа с Request -> Response), Doctrine Cache и просто собрать нужное. При этом можно быть на 99.9% уверенным, что там нет никаких ошибок. Например такие фреймворки, как Laravel, Lumen, Slim процентов на 30-50 состоят из его компонентов.
Ну и к тому же оно ставится одной строчкой: `composer install symfony/finder 2.5.*` (поставить в проект компонент работы с поиском файлов в ФС версии 2.5).
> а вот постоянное удаление composer.lock при разработке в большой команде очень сильно раздражало
composer.lock удалять нельзя — это список текущих установленных вендоров для того, чтоб при выполнении `composer install` на продакшене поставились именно эти версии (до самой минорной версии) пакетов, которые установлены локально, один-в-один. Для того, чтоб проигнорировать его и обновить все зависимости (с перезаписью lock-файла) есть команда `composer update`. И это всё есть в документации — первые абзацы.
> а вот virtualenvwrapper позволяет поставить все сторонние библиотеки в любое место на жестком диске, не ограничиваясь папкой vendors
Запустить композер с флагом `-g` для установки глобально или прописать в composer.json `vendor-dir` для указания каталога, куда нужно поставить всё (не в дефолтную папочку vendor)
> не вижу принципиальной разницы
pip install flask-*
еще проще в установке.
В таком случае думаю стоит именно его противопоставлять Symfony, а не монолитный Django. Разве нет?
composer.lock удалять нельзя — это список текущих установленных вендоров для того, чтоб при выполнении `composer install` на продакшене поставились именно эти версии (до самой минорной версии) пакетов, которые установлены локально, один-в-один. Для того, чтоб проигнорировать его и обновить все зависимости (с перезаписью lock-файла) есть команда `composer update`. И это всё есть в документации — первые абзацы.
> а вот virtualenvwrapper позволяет поставить все сторонние библиотеки в любое место на жестком диске, не ограничиваясь папкой vendors
Запустить композер с флагом `-g` для установки глобально или прописать в composer.json `vendor-dir` для указания каталога, куда нужно поставить всё (не в дефолтную папочку vendor)
> не вижу принципиальной разницы
pip install flask-*
еще проще в установке.
В таком случае думаю стоит именно его противопоставлять Symfony, а не монолитный Django. Разве нет?
В таком случае флакс — это микрофреймворк, сравнимый разве что со Slim или Lumen. А Symfony — это fullstack фреймворк, включающий в себя начиная с обычного MVC + Роутинг, заканчивая ОРМ и абстракцией над файловой системой.
Сам язык — PHP, имеет такую мощную штуку, как интерфейсы, которые позволяют реализовывать надёжный полиморфизм (если так можно выразиться). Благодаря чему хороший код на PHP всегда будет лучше кода языков, где нет инструмента, обеспечивающего гарантию полной реализации класса, например абстрактные классы (помимо интерфейсов). Тоже можно сказать и о явной инкапсуляции. Параллель можно провести с динамически-типизированными и статически-типизированными языками — второй вариант будет надёжнее и качественнее по вполне очевидным причинам.
Я не столь хорошо знаю питон, что бы утверждать что-то наверняка, но по-моему при сравнении абстрактного качества исходного кода в вакууме и пользуясь логикой из второго абзаца — вывод о том, что код на питоне более привлекателен и даже приводить в пример монолитный каркас, как доказательство — слишком уж опрометчиво. Вы не находите?
Сам язык — PHP, имеет такую мощную штуку, как интерфейсы, которые позволяют реализовывать надёжный полиморфизм (если так можно выразиться). Благодаря чему хороший код на PHP всегда будет лучше кода языков, где нет инструмента, обеспечивающего гарантию полной реализации класса, например абстрактные классы (помимо интерфейсов). Тоже можно сказать и о явной инкапсуляции. Параллель можно провести с динамически-типизированными и статически-типизированными языками — второй вариант будет надёжнее и качественнее по вполне очевидным причинам.
Я не столь хорошо знаю питон, что бы утверждать что-то наверняка, но по-моему при сравнении абстрактного качества исходного кода в вакууме и пользуясь логикой из второго абзаца — вывод о том, что код на питоне более привлекателен и даже приводить в пример монолитный каркас, как доказательство — слишком уж опрометчиво. Вы не находите?
> В таком случае думаю стоит именно его противопоставлять Symfony, а не монолитный Django. Разве нет?
Противопоставлять нужно всю компонентную базу PHP и Python, смысл выхватывать один Symphony? Из ZF тоже можно неплохо дёргать компоненты. Остальные библиотеки решающие частные задачи — можно воспринимать как немного более сложные компоненты — всему требуется та или иная адаптация в рамках своей «солянки».
Но в этом случае не получится сказать, что PHP богаче Python. Скорее наоборот — изначально модульный Python богаче, поскольку любой более менее общий код, который возможно использовать повторно, оформляется как общая библиотека, а не как компонент какого-то конкретного фреймворка и может быть легко подключён/использован. И так же изначально перед Python ставились более «серьёзные» задачи, экосистема языка протирается в глубины OS, в дебри научных исследований, на высоты обработки «больших данных». Было время я писал фоновые обработчики задач на PHP, поскольку веб-часть уже была на PHP, но Python постепенно всё вытеснил, поскольку «демоны» на нём значительно надёжнее и удобнее, библиотеки «суровее», постепенно он занял своё достойное место как язык встроенных процедур в базе данных. И постепенно назрела необходимость отказаться от двуязычия и перевести на Python и веб-часть.
И нужно признать, что Python, возможно не самый идеальный язык. Но именно если сравнивать его с PHP при решении задач в растущем бизнесе — PHP с усложнением проекта теряет все свои преимущества, а его недостатки выпирают всё сильнее.
Противопоставлять нужно всю компонентную базу PHP и Python, смысл выхватывать один Symphony? Из ZF тоже можно неплохо дёргать компоненты. Остальные библиотеки решающие частные задачи — можно воспринимать как немного более сложные компоненты — всему требуется та или иная адаптация в рамках своей «солянки».
Но в этом случае не получится сказать, что PHP богаче Python. Скорее наоборот — изначально модульный Python богаче, поскольку любой более менее общий код, который возможно использовать повторно, оформляется как общая библиотека, а не как компонент какого-то конкретного фреймворка и может быть легко подключён/использован. И так же изначально перед Python ставились более «серьёзные» задачи, экосистема языка протирается в глубины OS, в дебри научных исследований, на высоты обработки «больших данных». Было время я писал фоновые обработчики задач на PHP, поскольку веб-часть уже была на PHP, но Python постепенно всё вытеснил, поскольку «демоны» на нём значительно надёжнее и удобнее, библиотеки «суровее», постепенно он занял своё достойное место как язык встроенных процедур в базе данных. И постепенно назрела необходимость отказаться от двуязычия и перевести на Python и веб-часть.
И нужно признать, что Python, возможно не самый идеальный язык. Но именно если сравнивать его с PHP при решении задач в растущем бизнесе — PHP с усложнением проекта теряет все свои преимущества, а его недостатки выпирают всё сильнее.
В Ruby есть аналог Symfony — Sinatra.
Вот просто интересно… здесь все спорят какой скриптовой язык лучше… Постараюсь выделиться:
— если экосистема важнее — то почему не Java? Чем экосистема PHP лучше?
— если экосистема важнее — то почему не Java? Чем экосистема PHP лучше?
Примерно поэтому
Типичный процесс работы с Java: «Не хватает N компонента, пропишу-ка я в градле вот эту зависимость.». Остальной день тратится на то, чтоб подогнать объекты этого компонента к объектам уже существующего кода (если нет нормальных интерфейсов).
Типичный процесс работы с PHP: «Не хватает N компонента, пропишу-ка я в composer вот эту зависимость.». Остальной день тратится на то, чтоб выяснить внезапно появившиеся проблемы из-за его использования (если нет нормального покрытия тестами).
Конечно это всё ирония, но некоторая толика истины есть. В Java мне не нравится то, что каждый норовит реализовать свой объект для всех существующих в языке вещей, дополняя их, а потом дружить это всё довольно проблематично. В PHP — приходится зачастую исследовать исходники, чтоб понять хотя бы какие возможности есть и нормальный ли вообще код, можно ли его использовать.
Типичный процесс работы с PHP: «Не хватает N компонента, пропишу-ка я в composer вот эту зависимость.». Остальной день тратится на то, чтоб выяснить внезапно появившиеся проблемы из-за его использования (если нет нормального покрытия тестами).
Конечно это всё ирония, но некоторая толика истины есть. В Java мне не нравится то, что каждый норовит реализовать свой объект для всех существующих в языке вещей, дополняя их, а потом дружить это всё довольно проблематично. В PHP — приходится зачастую исследовать исходники, чтоб понять хотя бы какие возможности есть и нормальный ли вообще код, можно ли его использовать.
Вроде ничего не упустил
Список изменений и исправленийbugs.php.net/bug.php?id=50696
We are passing a (possibly uninitialized, or null-valued) variable to the function, in hundreds of places and web pages…И, насколько я понял, это и есть автор этой статьи…
We have number_format in literally thousands of places across 50 or 60 separate products...
Perl – почти так же хорош, как PHP, только без системы управления пакетами.Да уж конечно. Сколько лет прошло, а я до сих пор помню команду perl -MCPAN -e shell ← это и есть система управления пакетами.
Java – лучше, чем С, но всё ещё многословный и долго компилирующийся. Управление зависимостями было сложным делом.
Про многословность ладно — спорить нет смысла. А вот про управления зависимостями и время компиляции это что-то уж совсем клевета. Может быть просто я чего-то не знаю про те времена о которых говорит автор.
Прошу прощения, но помогите, пожалуйста, понять в чем цель данной статьи. В чем вообще цель статей, критикующих и только критикующих конкретный язык программирования/фреймворк?
Статья правильная, аргументированная.
Мнение фанатов в счет принимать не стоит.
Мнение фанатов в счет принимать не стоит.
Ну если уж JRuby — это будущее Ruby, то почему JPhp не может быть будущим PHP?
Впервые слышу про светлое будущее JRuby. Да и вообще разве у Ruby сейчас темное настоящее? )
А по поводу JPHP — а зачем, когда под JVM есть — Groovy, Scala, Ceylon, Kotlin etc.? Никогда не понимал людей, которые хотят писать под другие платформы/ниши, но при этом ленятся изучить новый язык.
А по поводу JPHP — а зачем, когда под JVM есть — Groovy, Scala, Ceylon, Kotlin etc.? Никогда не понимал людей, которые хотят писать под другие платформы/ниши, но при этом ленятся изучить новый язык.
Ну так основная ниша — веб-приложения — измениться от перехода на какой-нибудь JPHP не должна по идее
Я тоже, признаться, первый раз слышу о том, что JRuby — это светлое будущее Ruby. Но так написано в предпоследнем абзаце данного поста.
А Groovy, Scala, Ceylon, Kotlin, etc — это строготипизированные языки, в отличие от PHP. JPhp — это не альтренатива ни им, ни Zend-Based PHP — там своё АПИ, более приятное, нежели у оригинала и возможности той же Java. Он идеально подходит для прототипирования, когда скорость приложения не важна (да и жаловаться на скорость работы JPhp странновато, он всё же быстрее PHP, включая даже 7ку), а объём кода важен. Учитывая возможность беспроблемно перейти на более низкий уровень — перспективы написания всяких приложенец для стартапов по-моему идеальны.
А Groovy, Scala, Ceylon, Kotlin, etc — это строготипизированные языки, в отличие от PHP. JPhp — это не альтренатива ни им, ни Zend-Based PHP — там своё АПИ, более приятное, нежели у оригинала и возможности той же Java. Он идеально подходит для прототипирования, когда скорость приложения не важна (да и жаловаться на скорость работы JPhp странновато, он всё же быстрее PHP, включая даже 7ку), а объём кода важен. Учитывая возможность беспроблемно перейти на более низкий уровень — перспективы написания всяких приложенец для стартапов по-моему идеальны.
Люди пишут на Groovy, Scala и т.д. не ради того, что они исполняются на JVM. Непонятно откуда пошел такой миф, что если человек использует JVM язык то ему в первую очередь нужен язык, который бы выполнялся на JVM. JVM это лишь удобная платформа для имплементации различных языков.
У PHP есть главное преимущество перед другими языками — сверхнизкая стоимость кода. Точнее — сверхнизкая стоимость решения с помощью кода реальных задач. Пока другие языки не смогут его в этом вопросе превзойти — никакие доводы не сдвинут его с пьедестала самого популярного языка программирования. Пока мы живем при капитализме — именно деньги решают, who is hot and who is not.
Да, в том числе и этим. Низкая себестоимость = высокие конкурентные преимущества на рынке как специалиста.
Более вероятно что буду востребован именно я, при сравнимой продуктивности.
Или вы предлагаете писать на брэйнфаке и гордиться какая дорогая разработка выходит?
Более вероятно что буду востребован именно я, при сравнимой продуктивности.
Или вы предлагаете писать на брэйнфаке и гордиться какая дорогая разработка выходит?
Возможно, что все именно так, как вы говорите, но рынок не подтверждает ваших выводов.
Нужно понимать, что именно рынок выбирает. Язык выбирает заказчик, а не программист. И заказчик чаще выбирает именно PHP. По целому ряду причин.
Разумеется PHP не идеален. Разумеется есть языки лучше, круче, удобнее.
Но также как на автомобильном рынке по продажам лидирует весьма спорная Лада, также и на рынке разработки лидирует PHP, который выбирали, выбирают и будут выбирать потому, что он «дешев и сердит».
Нужно понимать, что именно рынок выбирает. Язык выбирает заказчик, а не программист. И заказчик чаще выбирает именно PHP. По целому ряду причин.
Разумеется PHP не идеален. Разумеется есть языки лучше, круче, удобнее.
Но также как на автомобильном рынке по продажам лидирует весьма спорная Лада, также и на рынке разработки лидирует PHP, который выбирали, выбирают и будут выбирать потому, что он «дешев и сердит».
Если у программиста PHP работа будет всегда, пусть и с более низкой оплатой, то сможет ли специалист на node.js найти себе стабильную и высокооплачиваемую работу — это еще вопрос.
Люди покупали и будут покупать машины. Но в кризисные времена люди в первую очередь перестанут покупать Роллс-Ройсы и скорее купят Ладу. И продавец Роллс-Ройсов будет вынужден либо затянуть пояса, либо вообще свернуть свой бизнес.
Вообще нужно смотреть всегда на объем рынка и соотношение спроса и предложения. Если рынок большой и спрос обгоняет предложение — значит для специалиста этот рынок перспективный. Если предложение обгоняет спрос, а объем рынка падает — то лучше с этого рынка уходить.
Ну и не вредно владеть несколькими языками программирования, чтобы иметь больше выбора.
Люди покупали и будут покупать машины. Но в кризисные времена люди в первую очередь перестанут покупать Роллс-Ройсы и скорее купят Ладу. И продавец Роллс-Ройсов будет вынужден либо затянуть пояса, либо вообще свернуть свой бизнес.
Вообще нужно смотреть всегда на объем рынка и соотношение спроса и предложения. Если рынок большой и спрос обгоняет предложение — значит для специалиста этот рынок перспективный. Если предложение обгоняет спрос, а объем рынка падает — то лучше с этого рынка уходить.
Ну и не вредно владеть несколькими языками программирования, чтобы иметь больше выбора.
Если говорить о вакансиях на полный рабочий день, то зарплаты(в СПб) фактически одинаковые. Поэтому возникает вопрос с чего вы взяли что кто-то выбирает менее оплачиваемую работу?
Удовольствие от работы на php можно получать не меньше чем на любом другом языке. Боюсь что всё неудобство с языком возникает от неумения его использовать.
Удовольствие от работы на php можно получать не меньше чем на любом другом языке. Боюсь что всё неудобство с языком возникает от неумения его использовать.
Боюсь что всё неудобстово с языком возникает от неумения его использовать.
Насколько по вашему релевантны претензии изложенные здесь?
eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design
Например строковые функции называются каждая на свой манер. Это не создает неудобства?
Вот так не удобней ли?
> Вот так не удобней ли?
С точки зрения «визуальной красоты» — удобнее. С точки зрения практики — однофигственно. Благо достаточно набрать «lowe», что б получить точно такой же список (из 3х функций) для перевода строковых данных в нижний регистр, вместо использования объектного интерфейса.
На скриншоте Вы приводите пример удобства использования IDE, а не языка. Благо в пыхе две строчки из скриншота сократятся до $number = (int)"42";, что по-моему ещё удобнее и проще.
С точки зрения «визуальной красоты» — удобнее. С точки зрения практики — однофигственно. Благо достаточно набрать «lowe», что б получить точно такой же список (из 3х функций) для перевода строковых данных в нижний регистр, вместо использования объектного интерфейса.
На скриншоте Вы приводите пример удобства использования IDE, а не языка. Благо в пыхе две строчки из скриншота сократятся до $number = (int)"42";, что по-моему ещё удобнее и проще.
С точки зрения «визуальной красоты» — удобнее. С точки зрения практики — однофигственно. Благо достаточно набрать «lowe», что б получить точно такой же список (из 3х функций) для перевода строковых данных в нижний регистр, вместо использования объектного интерфейса.
А он поймет, что какие-то функции нельзя применять к строчкам? Если нет единого стиля наименования я не знаю, будет ли слово полностью, или сокращено типа lcfirst.
две строчки из скриншота сократятся до $number = (int)«42»;, что по-моему ещё удобнее и проще.
Конечно, две строчки необязательно:
var number = "42".ToInt();
Конечно же поймёт: //habrastorage.org/files/158/611/287/1586112872e34c6db967df77ee07933f.jpg
PHP — язык с опциональной типизацией. Если все строготипизированные развиваются из строгой типизации в более слабую (темплейты, обощения и прочее, тот же String STL по сравнению с char* в сях), то в пыхе наоборот — можно использовать строгую там, где она нужна, в остальных случаях игнорировать.
PHP — язык с опциональной типизацией. Если все строготипизированные развиваются из строгой типизации в более слабую (темплейты, обощения и прочее, тот же String STL по сравнению с char* в сях), то в пыхе наоборот — можно использовать строгую там, где она нужна, в остальных случаях игнорировать.
Я так понимаю, что тип переменной $this это не строка.
В чем-то вы правы, но скорее развитие идет в направлении более легкой в использовании типизации, но строгой (вывод типов — вместо манифестной типизации, Generics и т.д.).
. Если все строготипизированные развиваются из строгой типизации в более слабую
В чем-то вы правы, но скорее развитие идет в направлении более легкой в использовании типизации, но строгой (вывод типов — вместо манифестной типизации, Generics и т.д.).
P.S. Не тот скриншот скинул, но это не важно особо — стандартные функции точно так же подсвечиваются с указанием возможных типов, аргументов и возвращаемых значений, просто изначально у любой скалярной переменной тип mixed (т.е. произвольный) и меняется в рантайме.
$this — это this, ссылка на себя. Я привёл в пример метод, где явно указал тип (в 5ой версии — аннотации, в 7ой — явное указание), но он не обязателен.
$this — это this, ссылка на себя. Я привёл в пример метод, где явно указал тип (в 5ой версии — аннотации, в 7ой — явное указание), но он не обязателен.
Нет ли проблемы что функции называются очень по разному.
например str_word_count — есть префикс, слова разделены пробелами, нет сокращений кроме префикса ucfirst — нет префикса, глагол сокращен.
например str_word_count — есть префикс, слова разделены пробелами, нет сокращений кроме префикса ucfirst — нет префикса, глагол сокращен.
Такая проблема безусловно есть.
Благо что эта проблема всем известна и её будут устранять в ближайшее время, вполне вероятно что это будет сделано уже в версии 7.1 (https://wiki.php.net/rfc/consistent_function_names)
Благо что эта проблема всем известна и её будут устранять в ближайшее время, вполне вероятно что это будет сделано уже в версии 7.1 (https://wiki.php.net/rfc/consistent_function_names)
Обычно только на момент изучения.
Есть конечно, проблема очевидна, но это проблема совсем уж зелёных новичков. Человек, который хоть немного пообщался с этим языком либо будет думать следующим образом «помню была такая функция, как её там, первую букву в верхний регистр, наберу first, о, вот она 'ucfirst'.», либо просто будет знать, либо воспользуется справкой\гуглом — это не страшно.
С другой стороны во многих языках даже нет аналогичных функций перевода самой первой буквы в верхний регистр или подсчёт количества слов в строке, но никто же их не осуждает?
Ещё одним плюсом можно назвать огромное комьюнити, где есть множество своих решений для исправления этой ситуации, причём они довольно просто совместимы друг с другом как раз благодаря слабой типизации, а не как, используя например Java или C# — приходится пройти все круги адовых абстракций, чтоб перегнать вендорный объект одного типа в другой.
С другой стороны во многих языках даже нет аналогичных функций перевода самой первой буквы в верхний регистр или подсчёт количества слов в строке, но никто же их не осуждает?
Ещё одним плюсом можно назвать огромное комьюнити, где есть множество своих решений для исправления этой ситуации, причём они довольно просто совместимы друг с другом как раз благодаря слабой типизации, а не как, используя например Java или C# — приходится пройти все круги адовых абстракций, чтоб перегнать вендорный объект одного типа в другой.
Мне кажется, что вы немного путаете разные системы типизации, другие ваши комментарии это тоже подтверждают. Они могут быть статическими и динамическими, строгими и нестрогими, явными и неявными, мономорфными и полиморфными (причём разными способами), и всё это достаточно ортогональные характеристики. И std::string не «слабее» char * в плане типов, а скорее наоборот.
Да, верно, постоянно путаю. Но думаю свою мысль я донёс, даже невзирая на то, что откровенно наврал в терминологии. Хоть в PHP и принята динамическая типизация для скаляров — её можно сделать статической (в виде подсветки IDE для PHP 5 или в виде исключений в PHP 7) в аргументах и возвращаемых значениях.
Тут qz.com/298635/these-programming-languages-will-earn-you-the-most-money есть Ruby on Rails, а тут qz.com/229570/here-are-most-valuable-skills-in-americas-tech-job-market нет. Поэтому эти результаты объявляю подозрительными. Если найдёте исходные данные, то будете молодцом.
Сложно сказать как проводилось исследование, но например вот здесь:
www.indeed.com/salary?q1=php&l1=&q2=python&l2=&q3=c%23&l3=&q4=c&l4=&q5=c%2B%2B&l5=&q6=javascript&l6=&q7=perl&l7=&q8=java&l8=&q9=ruby&l9=
информация совсем иная
И ни та ни другая статистика не показательна. Нужно сравнивать какие-то определённые условия что бы была зоть какая-то картина и объективность, но это не будет отражать действительность в других условиях. Так что на мой взгляд слова о том что на таком-то языке больше зарабатывают, звучит сомнительно.
www.indeed.com/salary?q1=php&l1=&q2=python&l2=&q3=c%23&l3=&q4=c&l4=&q5=c%2B%2B&l5=&q6=javascript&l6=&q7=perl&l7=&q8=java&l8=&q9=ruby&l9=
информация совсем иная
И ни та ни другая статистика не показательна. Нужно сравнивать какие-то определённые условия что бы была зоть какая-то картина и объективность, но это не будет отражать действительность в других условиях. Так что на мой взгляд слова о том что на таком-то языке больше зарабатывают, звучит сомнительно.
Не хлебом единым.
Без проблем.
ubiznes.ru/skolko-zarabatyvaet/kakaya-zarplata-u-programmistov.html
Здесь питона вообще нет.
Так что очевидно что нужно учить 1C!
ubiznes.ru/skolko-zarabatyvaet/kakaya-zarplata-u-programmistov.html
Здесь питона вообще нет.
Так что очевидно что нужно учить 1C!
www.tiobe.com/index.php/content/paperinfo/tpci/index.html А здесь руби в рейтинге языков на 15 месте, правда по популярности.
Я не говорю о гордости. Речь об общей экономической эффективности.
Он говорит с точки зрения работодателя, а не исполнителя
сверхнизкая стоимость кода
За счет чего?
За счет:
1) Простоты
2) Оптимизации для веба
3) Не нужно компилировать код
4) Слабая типизация
5) Много программистов
6) Более низкая зарплата программистов
7) Много бесплатных и платных CMS и Frameworkов
и прочее.
Все это вместе складывается в интегральную величину: «совокупная стоимость владения» которая у любого проекта на PHP в целом ниже, чем у проекта на любом другом языке.
1) Простоты
2) Оптимизации для веба
3) Не нужно компилировать код
4) Слабая типизация
5) Много программистов
6) Более низкая зарплата программистов
7) Много бесплатных и платных CMS и Frameworkов
и прочее.
Все это вместе складывается в интегральную величину: «совокупная стоимость владения» которая у любого проекта на PHP в целом ниже, чем у проекта на любом другом языке.
Можете сравнить с Питоном?
В чем простота и оптимизация для веба?
Слабая типизация (не путать со статической и манифестной) это разве преимущество?
В чем простота и оптимизация для веба?
Слабая типизация (не путать со статической и манифестной) это разве преимущество?
Да, это преимущество. Ускоряет разработку. Хотя и делает код менее понятным.
Также преимущество — терпимость языка к ошибкам программирования. Тоже ускоряет разработку и в итоге снижает затраты.
Хотя конечно же с точки зрения true кодера — это выглядит как недостаток.
Также преимущество — терпимость языка к ошибкам программирования. Тоже ускоряет разработку и в итоге снижает затраты.
Хотя конечно же с точки зрения true кодера — это выглядит как недостаток.
Мне кажется, это ускорят первичное написание кода, а не разработку в целом (включая исправление последующих ошибок). Хотя, если проект очень маленький и цена ошибки очень невысока…
Или просто дает ощущение скорости разработки.
Или просто дает ощущение скорости разработки.
Любую ошибку можно отловить и исправить. У меня все FatalException складываются в бд и видны в админке с бэктрейсом, доменом, файлом, строкой, переданными параметрами, и строкой запроса. Бывает там что то? Да. Сколько я это исправляю? минуту и уже хотфикс разворачивается на серверах.
Со слабой типизацией трейса не будет, просто по тихому данные загубятся
Почему же не будет? Почему загубятся? Я не в состоянии ожидать что то от входных данных? Я не знаю что там будет? Если там должно быть число — оно там и будет и я его строго приведу к числовому типу. Не будет число? Следовательно метод не может работать — кидаем fatal, сохраняем бэктрейс и видим что же погубило нашу функцию. Я не собираюсь спорить у меня это работает прямо сейчас.
Я так понял, что если вы забутете что-то к чему-то привести, оно по тизому приведется — не так?
«a» + 1 = «a1», а «1»+1 = 2 — не?
«a» + 1 = «a1», а «1»+1 = 2 — не?
нет, это работает не так.
«a»+1 = 1
«1»+1 = 2
«a»+«1»=1
для констатации строк используется dot оператор.
следовательно:
«a».1 = Fatal Exception.
«a».«1» = «a1»
«a»+1 = 1
«1»+1 = 2
«a»+«1»=1
для констатации строк используется dot оператор.
следовательно:
«a».1 = Fatal Exception.
«a».«1» = «a1»
Получше чем я думал, но все равно…
«a». 1 = «a1». без FatalError или FatalException (если мы про PHP).
Правда? sandbox.onlinephpfunctions.com/code/e9ff69d28991061b9a3f27348f409a26a2c76c57 Parse Error, но тем не менее. Я на php пишу каждый день и уже очень много лет. Свои слова я аргументирую.
хотя, я заметил пробел, но тем не менее сути это не меняет ;)
PHP 5.6
//habrastorage.org/files/b99/ebb/a64/b99ebba64b074ef2a5a0a2cdcf3c2a96.png
PHP 5.5
//sandbox.onlinephpfunctions.com/code/6168b24e8ec78e8ed17efb80e0f9591905acba68
Да, а без пробела не работает, т.к. ".2" преобразуется во флоат «0.2», но мы же тут конкатенацию рассматриваем. Но да, каюсь, не заметил отсутствие пробела в самом начале, по привычке (по PSR) поставил его.
//habrastorage.org/files/b99/ebb/a64/b99ebba64b074ef2a5a0a2cdcf3c2a96.png
PHP 5.5
//sandbox.onlinephpfunctions.com/code/6168b24e8ec78e8ed17efb80e0f9591905acba68
Да, а без пробела не работает, т.к. ".2" преобразуется во флоат «0.2», но мы же тут конкатенацию рассматриваем. Но да, каюсь, не заметил отсутствие пробела в самом начале, по привычке (по PSR) поставил его.
Есть подозрение что JavaScript таки это может сделать.
Хотелось бы мне, чтобы люди могли ответить мне на вопрос «почему бы я сегодня выбрал для себя PHP?».
Не очень понятен вопрос. Выбрал бы для чего? Навскидку варианты:
— сделать стандартный сайт (визитка, бложик или инет-магазин)
— как первый язык программирования
— как основной язык конкретного сложного веб-приложения
— как основной язык профессиональной деятельности
А вообще статья непонятна, что устарелого в PHP? Что в нём есть, что мешает разрабатывать? Каков идеал современного ЯП для разработки сервер-сайда веб-приложений разного уровня от бложика от монстров типа фэйсбука или внутрикорпоративных приложений? Какие отличия от этого идеала делают PHP устаревшим? Рассматривается сам язык, язык со стандартной библиотекой или вся экосистема?
Хммм… Вот честно, для меня проще написать инет-магазин на Java (тот же Play Framework), чем продираться через тысячи стандартных функций PHP. А до джавы — проще было на перле написать. Так что тут всё сугубо индивидуально, но я бы не советовал его к изучению, если бы ко мне обратились с таким вопросом.
Фейсбук, кстати, тоже отказался от PHP в пользу своей версии языка.
Фейсбук, кстати, тоже отказался от PHP в пользу своей версии языка.
О ну да… Автор открой для себя шелл cpan для Perl
PHP устарел, потому что я на нем писал в 2000 году
Будущее PHP это Go
Вот и меня минусуют за моё мнение к PHP. Ладно бы я был фанатом python/ruby, но нет, я пишу на php лет 10 и продолжаю это делать. И со всем своим опытом, я утверждаю, что php — плох, а мне не верят.
Признаюсь, я сам стал понимать глубину проблемы, только после начала изучения Go/Java/Scala.
Не верите мне? Посмотрите статистику использования PHP, популярность падает и поверьте, продолжит падать.
Признаюсь, я сам стал понимать глубину проблемы, только после начала изучения Go/Java/Scala.
Не верите мне? Посмотрите статистику использования PHP, популярность падает и поверьте, продолжит падать.
Опять молча минусуют глоры?!
И чем Java например лучше, можно поподробнее?
Пых:
1) Есть генераторы
2) Есть лямбды (java 1.8, но андроид поддерживает только 1.7)
3) Более строгая (внезапно!) работа с интерфейсами (только методы) и полями (только скаляры) — я считаю это плюсом, так как не позволяет размазывать логику.
4) Есть трейты
5) Один `[]` заменяет HashMap, HashSet, T[] (т.е. массивы) и прочее. Остальные структуры идентичны.
6) Есть магические методы, позволяющие имитировать любые структуры, начиная с функций, заканчивая объекты с бесконечным количеством полей.
7) В разы более краткий синтаксис, сопоставимый со Scala (но скала — это вообще отдельная история, там краткость достигается другим способом, я её не рассматриваю)
8) Более выразительный синтаксис позволяет с одного символа понять вызывается ли статик метод или метод инстанса.
9) По-моему более гибкая объектная модель (например как в джаве запилить позднее статическое связывание?). Тут можно поспорить.
Джава:
1) Есть безымянные классы (Есть в PHP 7.0+)
2) Есть внутренние классы (вообще спорный вопрос на счёт плюсов)
3) Есть перечисления (Существует соответствующее Rfc, вполне возможно будет в PHP 7.1)
4) Есть аннотации (В PHP эмулируется с помощью DocBlock)
5) Есть static конструктор
6) Языковые фичи (например итераторы) выглядят как дополнение, а не как вкостыленные в язык.
В остальном это почти одинаковые языки. А преимущества Java не столь явно выражены, как преимущества PHP. Хотя язык это всего лишь инструмент, и не буду отнекиваться — джава мне тоже нравится.
Пых:
1) Есть генераторы
2) Есть лямбды (java 1.8, но андроид поддерживает только 1.7)
3) Более строгая (внезапно!) работа с интерфейсами (только методы) и полями (только скаляры) — я считаю это плюсом, так как не позволяет размазывать логику.
4) Есть трейты
5) Один `[]` заменяет HashMap, HashSet, T[] (т.е. массивы) и прочее. Остальные структуры идентичны.
6) Есть магические методы, позволяющие имитировать любые структуры, начиная с функций, заканчивая объекты с бесконечным количеством полей.
7) В разы более краткий синтаксис, сопоставимый со Scala (но скала — это вообще отдельная история, там краткость достигается другим способом, я её не рассматриваю)
8) Более выразительный синтаксис позволяет с одного символа понять вызывается ли статик метод или метод инстанса.
9) По-моему более гибкая объектная модель (например как в джаве запилить позднее статическое связывание?). Тут можно поспорить.
Джава:
1) Есть безымянные классы (Есть в PHP 7.0+)
2) Есть внутренние классы (вообще спорный вопрос на счёт плюсов)
3) Есть перечисления (Существует соответствующее Rfc, вполне возможно будет в PHP 7.1)
4) Есть аннотации (В PHP эмулируется с помощью DocBlock)
5) Есть static конструктор
6) Языковые фичи (например итераторы) выглядят как дополнение, а не как вкостыленные в язык.
В остальном это почти одинаковые языки. А преимущества Java не столь явно выражены, как преимущества PHP. Хотя язык это всего лишь инструмент, и не буду отнекиваться — джава мне тоже нравится.
Оговорюсь, что в большинстве пишу не на java, a на scala, потому могу что-то спутать:
1. многопоточность (на мой вгляд этого достаточно)
2. I/O streams (в пхп что-то есть, но библиотек работающих на стримах почти нет)
3. type hinting (в пыхе лимита)
4. generics
5. method overloading
6. immutable structures
7. memory management (работа не со стеком, а с кучей)
8. non-blocking api
9. существующие библиотеки явно выше качеством
10. скорость
11. синтаксис в конце концов (вам не надоело всё время писать $this-> ?)
Это явно не полный список, но вполне хватaет чтоб задуматься над выбором при следующем проекте.
Моё видение того что вы упоминали про пхп:
1. спасибо nikic! еслиб не он… но посмотрите на его блог и в каком направлении думает парень.
2. от синтаксиса лямбд в php плакать хочется, и уже предвкушаю как тянусь за shift+` чтоб сократить до ~>
3. одно из немногих исключений, но не столь существенное
4. есть, но нет возможности указать upper/lower type bounds
5. это по вашему плюс???
6. магические методы скорее признак архитектурных проблем, чем реальные решения. С ide проблемы, с тестированием проблемы, а reflections?
7. были у меня глупые попытки перевести java либу на php, за отсутствием хороших реализаций у последнего. Не могу однозначно сказать, что синтаксис у пхп короче.
Про scala тут вообще молчком. Если поддерживаете взгляды и идеи М.Odersky, то php можно сразу в гроб класть.
1. многопоточность (на мой вгляд этого достаточно)
2. I/O streams (в пхп что-то есть, но библиотек работающих на стримах почти нет)
3. type hinting (в пыхе лимита)
4. generics
5. method overloading
6. immutable structures
7. memory management (работа не со стеком, а с кучей)
8. non-blocking api
9. существующие библиотеки явно выше качеством
10. скорость
11. синтаксис в конце концов (вам не надоело всё время писать $this-> ?)
Это явно не полный список, но вполне хватaет чтоб задуматься над выбором при следующем проекте.
Моё видение того что вы упоминали про пхп:
1. спасибо nikic! еслиб не он… но посмотрите на его блог и в каком направлении думает парень.
2. от синтаксиса лямбд в php плакать хочется, и уже предвкушаю как тянусь за shift+` чтоб сократить до ~>
3. одно из немногих исключений, но не столь существенное
4. есть, но нет возможности указать upper/lower type bounds
5. это по вашему плюс???
6. магические методы скорее признак архитектурных проблем, чем реальные решения. С ide проблемы, с тестированием проблемы, а reflections?
7. были у меня глупые попытки перевести java либу на php, за отсутствием хороших реализаций у последнего. Не могу однозначно сказать, что синтаксис у пхп короче.
Про scala тут вообще молчком. Если поддерживаете взгляды и идеи М.Odersky, то php можно сразу в гроб класть.
1) Есть такое дело, но с другой стороны в пыхе она не нужна и требуется очень редко (с другой стороны в PHP есть класс Thread, предоставляющий такую возможность)
2) I/O стримы — php://, phar://, http:// и прочее — это встроенные стримы, их можно даже создавать самому, там ничего сложного. На счёт библиотек — SymfonyHttpCore (Response), Ratchet, React — это если сходу назвать. Не уверен на 100%, но наверняка. Ну и генераторы заменяют половину возможностей стримов.
3) Простите, в пыхе что?
4) Это благодаря строгой типизации, смысла для слаботипизированных языков в этом не особо
5) см п.4
6,7) Затрудняюсь ответить
8) Имеется ввиду shared memory? Или возможность читать файлы и сокеты без блокировок? Тогда это есть.
9) Это спорно, давеча познакомился с javazoom jlayer — единственный из существующих вменяемый вариант проигрывать mp3. Так там чёрт ногу сломит. С другой стороны если открыть исходники Симфони — они по качеству кода с Хибернейтом могут поспорить. Так что это смотря что и где, но в целом утверждение наверное верное, всё же энтерпрайз.
10) Тоже спорно gist.github.com/dstogov/12323ad13d3240aee8f1#file-b-txt Но тоже в целом верно
11) Синтаксис — это очень спорная вещь. Мне надоело использовать точку для указания как вызова статика, так и метода инстанса. Мне надоело использовать математический оператор для конкатенации строк, а не, например, сложения его чаркодов. Мне не нравится, что для вызова статика нужно указывать класс, для исключений обязательно указывать throws и так далее. Тут можно похоливарить, но в целом я считаю синтаксис пыха более логичным и строгим.
2) I/O стримы — php://, phar://, http:// и прочее — это встроенные стримы, их можно даже создавать самому, там ничего сложного. На счёт библиотек — SymfonyHttpCore (Response), Ratchet, React — это если сходу назвать. Не уверен на 100%, но наверняка. Ну и генераторы заменяют половину возможностей стримов.
3) Простите, в пыхе что?
4) Это благодаря строгой типизации, смысла для слаботипизированных языков в этом не особо
5) см п.4
6,7) Затрудняюсь ответить
8) Имеется ввиду shared memory? Или возможность читать файлы и сокеты без блокировок? Тогда это есть.
9) Это спорно, давеча познакомился с javazoom jlayer — единственный из существующих вменяемый вариант проигрывать mp3. Так там чёрт ногу сломит. С другой стороны если открыть исходники Симфони — они по качеству кода с Хибернейтом могут поспорить. Так что это смотря что и где, но в целом утверждение наверное верное, всё же энтерпрайз.
10) Тоже спорно gist.github.com/dstogov/12323ad13d3240aee8f1#file-b-txt Но тоже в целом верно
11) Синтаксис — это очень спорная вещь. Мне надоело использовать точку для указания как вызова статика, так и метода инстанса. Мне надоело использовать математический оператор для конкатенации строк, а не, например, сложения его чаркодов. Мне не нравится, что для вызова статика нужно указывать класс, для исключений обязательно указывать throws и так далее. Тут можно похоливарить, но в целом я считаю синтаксис пыха более логичным и строгим.
1. phthreads — костыль. Идеология пхп умирать не даст вам работать в многопоточности. Потоки и так непростая штука, а бороться еще и с языком… извольте, я просто возьму Акка.
2. стримы есть, а толку? Хоть кто нибудь их использует? Библиотек нет, а react/ratchet построен na libevent — костыль.
П.С. У меня есть статья с исходниками по привязке react на планировщик, построенный на генераторах, и это всё запускает symfony2. Но это всё лабораторные испытания, и совсем не готово для боевых задач.
3. type hinting в пхп ограниченный, даже в 7
4. с введением строгой типизации это становится актуальным, в hack именно так обстоят дела
5. бросьте, даже в 5.5 перегрузка методов былаб очень кстати.
8. есть, мало, но есть, а неблокирующих расширений и того меньше… в результате толку ноль ((
11. согласен, это спорно. Но тут я руководствуюсь краткостью и распространённостью среди других языков.
2. стримы есть, а толку? Хоть кто нибудь их использует? Библиотек нет, а react/ratchet построен na libevent — костыль.
П.С. У меня есть статья с исходниками по привязке react на планировщик, построенный на генераторах, и это всё запускает symfony2. Но это всё лабораторные испытания, и совсем не готово для боевых задач.
3. type hinting в пхп ограниченный, даже в 7
4. с введением строгой типизации это становится актуальным, в hack именно так обстоят дела
5. бросьте, даже в 5.5 перегрузка методов былаб очень кстати.
8. есть, мало, но есть, а неблокирующих расширений и того меньше… в результате толку ноль ((
11. согласен, это спорно. Но тут я руководствуюсь краткостью и распространённостью среди других языков.
1. Идеология не мешает ему иметь вменяемый GC и работать в многопоточном режиме (например как модуль апача). С другой стороны подход «умирать» намного более удобен, нежели заниматься весельем с отловом утечек или синхронизацией тредов. А для оптимизаций почти всегда место найдётся в алгоритмах и sql. Короче, отсутствие нормальных потоков (внутри языка) и очистка пользовательской памяти после завершения работы — это меньшее зло, которое в значительной степени профитнее (если не обращать внимание на скорость, которую можно в теории значительно повысить, сделав нормальный рантайм).
2. Не построен, а «может использовать» — это разные вещи.
4. Ну если рассматривать Hack, то можно и Jphp рассматривать, а там есть всё, что есть в джаве, плюс всё, что есть в пыхе (ну и во всех Jvm языках, скрещивать никто не мешает). Тут будет однозначное поражение Java =)
5. Перегрузка только по количеству аргументов будет надёжной, да и то при variadic (...$args или func_get_args) может случиться адовый ад. Так что всё же по-моему это прерогатива статической типизации, где нет альтернативных возможностей. Плюс немного страдает магия рефлексии из-за «конфликта» имён; Вспомните как получить метод в джаве? Там надо перечислить помимо имени все аргументы и их свойства (обычный\variadic), хорошо что паспортные данные не требует :) Конечно да, перегрузка — это удобно, но в пыхе просто подход другой, с обратной стороны — проверка типов и количества в одном месте (если требуется), а не в нескольких. Да и уже давно все привыкли писать несколько разных методов, например «Point2::createFromPoint3(Point3 $point)» и «Point::createFromCoord($x, $y)». Ну т.е. согласен, но на половину, удобно, но всё же всунуть в пых будет сложно (если вообще возможно).
8. Ну это да. Просто никому они нафиг не нужны, до тех пор, пока не потребуется отдавать большие файлы или отправлять поток на вывод, т.е. совсем уж редкие задачи, для которых и сервера зачастую достаточно. Отсюда и малое количество нормальных решений.
11. На счёт распространённости согласен. Он местами даже уродлив. Но многие вещи зачастую избавляют от проблем слаботипизированных языков, взять хотя бы «string» + 42 = 42, а «string». 42 = «string42». Тоже и касается стрелочки — это только инстанс (объект) и всё, никаких исключений. Двойное двоеточие, тоже без исключений — статический вызов. По долларам можно запросто отличать переменную от константы (любой, хоть структуры или дефайна). Так что может синтаксис и на символ длиннее джавовского, но отсутствие обязательной типизации сокращает код намного больше, а читать его становится проще, просто благодаря изыбточности, но отнюдь не излишней избыточности. Опять же меньшее зло во благо.
2. Не построен, а «может использовать» — это разные вещи.
4. Ну если рассматривать Hack, то можно и Jphp рассматривать, а там есть всё, что есть в джаве, плюс всё, что есть в пыхе (ну и во всех Jvm языках, скрещивать никто не мешает). Тут будет однозначное поражение Java =)
5. Перегрузка только по количеству аргументов будет надёжной, да и то при variadic (...$args или func_get_args) может случиться адовый ад. Так что всё же по-моему это прерогатива статической типизации, где нет альтернативных возможностей. Плюс немного страдает магия рефлексии из-за «конфликта» имён; Вспомните как получить метод в джаве? Там надо перечислить помимо имени все аргументы и их свойства (обычный\variadic), хорошо что паспортные данные не требует :) Конечно да, перегрузка — это удобно, но в пыхе просто подход другой, с обратной стороны — проверка типов и количества в одном месте (если требуется), а не в нескольких. Да и уже давно все привыкли писать несколько разных методов, например «Point2::createFromPoint3(Point3 $point)» и «Point::createFromCoord($x, $y)». Ну т.е. согласен, но на половину, удобно, но всё же всунуть в пых будет сложно (если вообще возможно).
8. Ну это да. Просто никому они нафиг не нужны, до тех пор, пока не потребуется отдавать большие файлы или отправлять поток на вывод, т.е. совсем уж редкие задачи, для которых и сервера зачастую достаточно. Отсюда и малое количество нормальных решений.
11. На счёт распространённости согласен. Он местами даже уродлив. Но многие вещи зачастую избавляют от проблем слаботипизированных языков, взять хотя бы «string» + 42 = 42, а «string». 42 = «string42». Тоже и касается стрелочки — это только инстанс (объект) и всё, никаких исключений. Двойное двоеточие, тоже без исключений — статический вызов. По долларам можно запросто отличать переменную от константы (любой, хоть структуры или дефайна). Так что может синтаксис и на символ длиннее джавовского, но отсутствие обязательной типизации сокращает код намного больше, а читать его становится проще, просто благодаря изыбточности, но отнюдь не излишней избыточности. Опять же меньшее зло во благо.
1. Это, кстати, одна из проблем php — он «создан, чтобы умирать».
5. Зато улучшает понимание и управление… Только я бы ещё упомянул тут и method overriding.
8. Скорее всего, имеются в виду структуры для многопоточного программирования.
10. Не стоит на него операться… строчки:
Date d2 = new Date();
long diff = d2.getTime() — d1.getTime();
уже говорят о дурном подходе к тестированию… да и
System.out.print("\n");
внутри циклов — тоже доставляют.
Есди вам интересно почему:
— Date — очень тяжеловесный объект, создание которого занимает чудовищно много времени (относительно собственно рассчёта). Если хочется считать — нужно использовать System.currentTimeMillis() или System.nanoTime() (в последнем случае — нужно учитывать, что счётчик может переполниться)
— поток System.out подключается то ли напрямую, то ли через очень маленький буфер к консоли, а это работа с системными потоками и это долго. В идеале, для рассчёта стоимости алгоритма надо было использовать StringBuilder и вывод в консоль из него после выполнения операций.
Скорее всего эти же проблемы касаются остальных языков.
11.
— точка — это дело привычки,
— используйте тип char и сможете складывать чаркоды. Строки в Java всегда содержат как минимум 2 чаркода (см utf-16). Это дело привычки,
— Простите, а в php можно статик-метод класса вызывать без использования имения класса? Внутри класса — можно имя класса опускать, так же как и для вызовов методов инстанса.
— используйте unchecked (потомки RuntimeException) исключения — их можно кидать без throws. Только это… свинство, мягко говоря… Напоролся тут недавно — выскочило исключение, которого не ждал… И сломало загрузку модуля.
5. Зато улучшает понимание и управление… Только я бы ещё упомянул тут и method overriding.
8. Скорее всего, имеются в виду структуры для многопоточного программирования.
10. Не стоит на него операться… строчки:
Date d2 = new Date();
long diff = d2.getTime() — d1.getTime();
уже говорят о дурном подходе к тестированию… да и
System.out.print("\n");
внутри циклов — тоже доставляют.
Есди вам интересно почему:
— Date — очень тяжеловесный объект, создание которого занимает чудовищно много времени (относительно собственно рассчёта). Если хочется считать — нужно использовать System.currentTimeMillis() или System.nanoTime() (в последнем случае — нужно учитывать, что счётчик может переполниться)
— поток System.out подключается то ли напрямую, то ли через очень маленький буфер к консоли, а это работа с системными потоками и это долго. В идеале, для рассчёта стоимости алгоритма надо было использовать StringBuilder и вывод в консоль из него после выполнения операций.
Скорее всего эти же проблемы касаются остальных языков.
11.
— точка — это дело привычки,
— используйте тип char и сможете складывать чаркоды. Строки в Java всегда содержат как минимум 2 чаркода (см utf-16). Это дело привычки,
— Простите, а в php можно статик-метод класса вызывать без использования имения класса? Внутри класса — можно имя класса опускать, так же как и для вызовов методов инстанса.
— используйте unchecked (потомки RuntimeException) исключения — их можно кидать без throws. Только это… свинство, мягко говоря… Напоролся тут недавно — выскочило исключение, которого не ждал… И сломало загрузку модуля.
> Используйте тип char и сможете складывать чаркоды. Строки в Java всегда содержат как минимум 2 чаркода (см utf-16). Это дело привычки,
В PHP для конкатенации используется точка — это возможность проводить строковые операции отдельно, а математические отдельно. Предлагаю взглянуть на JS, где "+" представляет из себя и то и другое. Много веселья можно обнаружить. Когда код начинает выдавать совершенно невообразимые результаты, просто из-за проблемы динамической типизации.
> Простите, а в php можно статик-метод класса вызывать без использования имения класса?
Да, конечно.
1) Можно от строки вызвать, тогда строка попытается сконвертиться в декларацию класса
2) Можно вызвать из родителя с помощью static
3) Можно вызвать из ребёнка c помощью parent
4) Можно обратиться через рефлексию и ещё тучей всяких способов
> Напоролся тут недавно — выскочило исключение, которого не ждал… И сломало загрузку модуля.
Ну наверное в случае Java throws полезны. Обычно исключениями хочется покидать всякие NotFonudHttpException, PermissionDeniedException, просто по привычке, а чтоб это нормально в java обработать — приходится исправлять километры кода. Но наличие явных мест вылета исключений — несомненный плюс.
В PHP для конкатенации используется точка — это возможность проводить строковые операции отдельно, а математические отдельно. Предлагаю взглянуть на JS, где "+" представляет из себя и то и другое. Много веселья можно обнаружить. Когда код начинает выдавать совершенно невообразимые результаты, просто из-за проблемы динамической типизации.
> Простите, а в php можно статик-метод класса вызывать без использования имения класса?
Да, конечно.
1) Можно от строки вызвать, тогда строка попытается сконвертиться в декларацию класса
2) Можно вызвать из родителя с помощью static
3) Можно вызвать из ребёнка c помощью parent
4) Можно обратиться через рефлексию и ещё тучей всяких способов
> Напоролся тут недавно — выскочило исключение, которого не ждал… И сломало загрузку модуля.
Ну наверное в случае Java throws полезны. Обычно исключениями хочется покидать всякие NotFonudHttpException, PermissionDeniedException, просто по привычке, а чтоб это нормально в java обработать — приходится исправлять километры кода. Но наличие явных мест вылета исключений — несомненный плюс.
> В PHP для конкатенации используется точка — это возможность проводить строковые операции отдельно, а математические отдельно. Предлагаю взглянуть на JS, где "+" представляет из себя и то и другое. Много веселья можно обнаружить. Когда код начинает выдавать совершенно невообразимые результаты, просто из-за проблемы динамической типизации.
Тут есть нюанс: в Java статическая типизация и в Java единственное место, где переопределён смысл оператора + — это строки. Поведение однозначное, проблемм не возникает.
>> Простите, а в php можно статик-метод класса вызывать без использования имения класса?
> Да, конечно.
> 1) Можно от строки вызвать, тогда строка попытается сконвертиться в декларацию класса
> 2) Можно вызвать из родителя с помощью static
> 3) Можно вызвать из ребёнка c помощью parent
> 4) Можно обратиться через рефлексию и ещё тучей всяких способов
Не улавливаю чем 1 случай отличается от базового. Насчёт 2го и 3го не скажу — достаточно специфические случаи, а 4ый в равной степени относится к жаве.
Тут есть нюанс: в Java статическая типизация и в Java единственное место, где переопределён смысл оператора + — это строки. Поведение однозначное, проблемм не возникает.
>> Простите, а в php можно статик-метод класса вызывать без использования имения класса?
> Да, конечно.
> 1) Можно от строки вызвать, тогда строка попытается сконвертиться в декларацию класса
> 2) Можно вызвать из родителя с помощью static
> 3) Можно вызвать из ребёнка c помощью parent
> 4) Можно обратиться через рефлексию и ещё тучей всяких способов
Не улавливаю чем 1 случай отличается от базового. Насчёт 2го и 3го не скажу — достаточно специфические случаи, а 4ый в равной степени относится к жаве.
> Не улавливаю чем 1 случай отличается от базового.
Ну наверное тем, что это всё же не декларация класса и поведение у них разное:
```
<?php
use Some\Any as Test;
echo Test::class // Some\Any;
$className = «Test»;
echo $className::class // Error, can not find class Test
```
2 и 3 — не специфичные случаи, а вполне себе актуальные. Вызов super в джаве как раз и есть один из них (super(42) в java; parent::someMethod(42) в php). Со статиком в обратную сторону — называется позднее статическое связывание и это тоже довольно популярный подход, чтоб иметь возможность переопределять статические методы:
```
<?php
class ParentClass
{
....public static function print()
....{
........echo static::class. "\n";
........echo self::class. "\n";
....}
}
class A extends ParentClass {}
A::print();
// A (т.е. обращение к месту вызова, контекст его класса)
// ParentClass (обращение к месту объявления)
```
> а 4ый в равной степени относится к жаве.
Ну это да =)
З.Ы. Прошу прощения за отсутствие форматирования кода, карма.
Ну наверное тем, что это всё же не декларация класса и поведение у них разное:
```
<?php
use Some\Any as Test;
echo Test::class // Some\Any;
$className = «Test»;
echo $className::class // Error, can not find class Test
```
2 и 3 — не специфичные случаи, а вполне себе актуальные. Вызов super в джаве как раз и есть один из них (super(42) в java; parent::someMethod(42) в php). Со статиком в обратную сторону — называется позднее статическое связывание и это тоже довольно популярный подход, чтоб иметь возможность переопределять статические методы:
```
<?php
class ParentClass
{
....public static function print()
....{
........echo static::class. "\n";
........echo self::class. "\n";
....}
}
class A extends ParentClass {}
A::print();
// A (т.е. обращение к месту вызова, контекст его класса)
// ParentClass (обращение к месту объявления)
```
> а 4ый в равной степени относится к жаве.
Ну это да =)
З.Ы. Прошу прощения за отсутствие форматирования кода, карма.
Ну это уже какие-то чисто php-заморочки, которые мне не понять:
use Some\Any as Test;
2ой и 3ий для меня так и остаются сомнительным юз-кейсом.
use Some\Any as Test;
2ой и 3ий для меня так и остаются сомнительным юз-кейсом.
Это не чисто php-заморочки. Это алиасы, которые есть и в Python (import some as any), ActionScript (import Some = any), CoffeeScript ({Some} = Any), C# (using Any = Some) и в прочих.
2 и 3 пункты позволяют более гибко оперировать объектами. По-умолчанию в Java классах при наследовании для статик-методов используется переопределение (поправьте, если я ошибаюсь) и все вызовы без явного указания класса будут обращаться к ребёнку (да ведь?) — в php это аналогично всем `static::*` вызовам. Но в случае когда нужно обратиться конкретно к полю своего класса, а не к будущим потомкам, которые его переопределят — используется `self::*`, что в Java реализуется лишь через `ИмяКласса.метод`.
2 и 3 пункты позволяют более гибко оперировать объектами. По-умолчанию в Java классах при наследовании для статик-методов используется переопределение (поправьте, если я ошибаюсь) и все вызовы без явного указания класса будут обращаться к ребёнку (да ведь?) — в php это аналогично всем `static::*` вызовам. Но в случае когда нужно обратиться конкретно к полю своего класса, а не к будущим потомкам, которые его переопределят — используется `self::*`, что в Java реализуется лишь через `ИмяКласса.метод`.
+сы PHP:
1. Сомнительный плюс… если опираться на статью habrahabr.ru/post/189796 — в Java итераторы проще, поэтому нет сложности с их переопределением… но можно обойтись и без них — в зависимости от решаемой задачи можно применять множество разных готовых библиотек.
2. Если мы говорим про веб, то при чём тут андроид? Андроид — строго говоря не Java.
3. И что же с интерфейсами в Java не так?
5. Все эти HashSet, TreeSet, T[] и т.д. — имеют разное назначение, цену использования и способ написания. Можно пользоваться и одним, но когда инструмент заточен под конкретную задачу — его легче использовать в этой конкретной задаче.
6. В Java всё, кроме primitive types, является Object. Даже имитировать ничего не надо. А для конкретной задачи — используется конкртеный интерфейс/класс.
7. Лучше я буду видеть более многословный синтаксис Java, чем разбираться «а откуда здесь SomeObject».
8. В Java действительно можно вызвать статический метод на объекте… но это категорически не приветствуется — поэтому тоже прекрасно видно — где и какой метод используется.
9. DI? Java Agents? Инструментация кода?
+сы Java
5. static конструктор — это что за зверь?
PS они ни разу не одинаковые языки. Их цели, их средства, их мировоззрение — они отличны во всём. Из общего — только какие-то языковые технологии/решения. И преимущества для себя каждый определяет сам — для себя я давно определил их в Java.
1. Сомнительный плюс… если опираться на статью habrahabr.ru/post/189796 — в Java итераторы проще, поэтому нет сложности с их переопределением… но можно обойтись и без них — в зависимости от решаемой задачи можно применять множество разных готовых библиотек.
2. Если мы говорим про веб, то при чём тут андроид? Андроид — строго говоря не Java.
3. И что же с интерфейсами в Java не так?
5. Все эти HashSet, TreeSet, T[] и т.д. — имеют разное назначение, цену использования и способ написания. Можно пользоваться и одним, но когда инструмент заточен под конкретную задачу — его легче использовать в этой конкретной задаче.
6. В Java всё, кроме primitive types, является Object. Даже имитировать ничего не надо. А для конкретной задачи — используется конкртеный интерфейс/класс.
7. Лучше я буду видеть более многословный синтаксис Java, чем разбираться «а откуда здесь SomeObject».
8. В Java действительно можно вызвать статический метод на объекте… но это категорически не приветствуется — поэтому тоже прекрасно видно — где и какой метод используется.
9. DI? Java Agents? Инструментация кода?
+сы Java
5. static конструктор — это что за зверь?
PS они ни разу не одинаковые языки. Их цели, их средства, их мировоззрение — они отличны во всём. Из общего — только какие-то языковые технологии/решения. И преимущества для себя каждый определяет сам — для себя я давно определил их в Java.
Как там в 2015 — уже привинтили юникод-то?
Один `[]` заменяет HashMap, HashSet, T[] (т.е. массивы) и прочееИ оттого работает чудовищно неэффективно по памяти.
Всегда доставляли такие комменты. Вы сравниваете JVM над которой трудятся одни из лучших программистов с PHP, который пилится можно сказать сообществом и энтузиастами. «Есть то, есть се» — это спорные утверждения, то что они есть это еще не значит, что это работает нормально. Взять хотя бы аннотации в комментариях — это вообще нормально!?
Ничего не имею против PHP — потому что не пишу на нем и не собираюсь. Но не нужно делать таких вот утверждений. Когда такое говорят в мире где-то грустит один инженер Oracle…
Ничего не имею против PHP — потому что не пишу на нем и не собираюсь. Но не нужно делать таких вот утверждений. Когда такое говорят в мире где-то грустит один инженер Oracle…
Меня поражают все эти нападки на язык. Язык лишь инструмент. Функции как-то не по стандарту названы… да я если честно уже не помню когда в последний раз возникали проблемы с этим… IDE(прекрасный PhpStorm от JetBrains) в руки и вперед.
Пишу сейчас на laravel… IoC из коробки. Куча современных паттернов из коробки. Composer — подключаешь что нужно. Пишется легко. Просто уметь надо.
Уже который раз замечаю, что люди, хаящие PHP, просто не умеют его готовить. До сих пор застряли на сайтах из одного PHP файла? include 'database.php'; — где подключаемся к базе данных?
Ну могу лишь предположить что достался большой legacy проект… Видел и такие. Но это проблема проекта, а не языка. Большие legacy проекты есть в каждом языке. Не надо сравнивать старый сайт на PHP и новый сайт на питоне/руби.
Пишу сейчас на laravel… IoC из коробки. Куча современных паттернов из коробки. Composer — подключаешь что нужно. Пишется легко. Просто уметь надо.
Уже который раз замечаю, что люди, хаящие PHP, просто не умеют его готовить. До сих пор застряли на сайтах из одного PHP файла? include 'database.php'; — где подключаемся к базе данных?
Ну могу лишь предположить что достался большой legacy проект… Видел и такие. Но это проблема проекта, а не языка. Большие legacy проекты есть в каждом языке. Не надо сравнивать старый сайт на PHP и новый сайт на питоне/руби.
Нападки на язык не ради того чтоб обидеть, язык или разработчиков, а от того, что обидно за php, которому уделял столько времени.
При разработке настаёт момент, когда понимаешь, что решить элегантно проблему на php невозможно, только с помощью костылей или сторонних утилит, а большинство разрабов, такие решения считают нормальными!
Можно возразить, мол вы же знали что php это в прошлом (personal home page), но так случается, что проекты вырастают, иногда больше ожидаемого и тут php подводит.
При разработке настаёт момент, когда понимаешь, что решить элегантно проблему на php невозможно, только с помощью костылей или сторонних утилит, а большинство разрабов, такие решения считают нормальными!
Можно возразить, мол вы же знали что php это в прошлом (personal home page), но так случается, что проекты вырастают, иногда больше ожидаемого и тут php подводит.
С ходу могу назвать только одну вещь, которая в пыхе делается костылями — прокси класс для DI. С удовольствием бы выслушал ещё примерчики, может действительно это случай «не умеешь готовить»?
Отложенное выполнение задач.
1) register_shutdown_function
2) Thread (http://php.net/manual/ru/class.thread.php)
3) Pcntl
4) Cron
А вообще по-хорошему (даже не на PHP) задачи — это некая сущность, которая должна выполняться вне основного треда, включая перезапуск при исключениях и прочее. Так что в данном случае лучше использовать Redis и аналогичные системы, ну или в БД отправлять задачу.
2) Thread (http://php.net/manual/ru/class.thread.php)
3) Pcntl
4) Cron
А вообще по-хорошему (даже не на PHP) задачи — это некая сущность, которая должна выполняться вне основного треда, включая перезапуск при исключениях и прочее. Так что в данном случае лучше использовать Redis и аналогичные системы, ну или в БД отправлять задачу.
Ну я же говорил, что можно сделать с помощю сторонних утилит(cron, queue) или костылей (pcntl, phthreads, shutdown_functions).
Поправьте если не прав… но чтоб решить задачу отложенных действий в пхп, нужно добавить асинхронность, а лучше многопоточность, но чтоб это добавить нужно переписать сборщик мусора, переписать расширения чтоб гарантированно (в основных) не текла память, а потом еще раз переписать чтоб вызовы были неблокирующие…
А если это всё сделать, то и мои претензии к пхп сойдут на близкое к нет.
Поправьте если не прав… но чтоб решить задачу отложенных действий в пхп, нужно добавить асинхронность, а лучше многопоточность, но чтоб это добавить нужно переписать сборщик мусора, переписать расширения чтоб гарантированно (в основных) не текла память, а потом еще раз переписать чтоб вызовы были неблокирующие…
А если это всё сделать, то и мои претензии к пхп сойдут на близкое к нет.
Ну так и в руби, чтоб половину возможностей получить нужно компилить через devkit с шаманством gcc, никто же не жалуется? В целом — всё верно, встроенных возможностей нет, т.е. нет поддержки у шаред хостингов. Но я имел ввиду проблемы языка (т.е. проблемы при реализации ООП паттернов, например), а не его АПИ.
Так что имхо, такие возможности есть, возможности не костыльные (thread — это потоки, pcntl — это процессы), а то, что это dll\so — это уже другой вопрос. Костылём можно посчитать, например запущенный процесс пыха, как менеджера очередей, и общение с ним через сокеты или шаред мемори.
Так что имхо, такие возможности есть, возможности не костыльные (thread — это потоки, pcntl — это процессы), а то, что это dll\so — это уже другой вопрос. Костылём можно посчитать, например запущенный процесс пыха, как менеджера очередей, и общение с ним через сокеты или шаред мемори.
А я и не говорю за руби или питон… У меня там слишком мало опыта.
Потоки для пхп — костыль. Потому что неродное, потому что работать будет только в каких-то исключительных ситуациях, но не как mainstream. Не костыль для пхп это асинхронность средствами генераторов, хотя и это выглядит побочным эффектом.
Потоки для пхп — костыль. Потому что неродное, потому что работать будет только в каких-то исключительных ситуациях, но не как mainstream. Не костыль для пхп это асинхронность средствами генераторов, хотя и это выглядит побочным эффектом.
Ну так задачи, из реальной жизни, где прямо срочно нужны потоки — практически мифические. Вы привели в пример очереди, для них существуют специальные сервера очередей (RabbitMQ), существуют общие решения (Redis, Taratool, SQL-Like DB, etc...) и даже в языках, где есть нативная поддержка тредов — вряд ли будут их использовать для этого, разве что как временное решение.
Отложенное выполнение задач не должно выполняться веб сервером, для этого есть крон или сервисы очереди задач.
Выполнять отложенные задачи создавая ещё один поток (или пользуясь пулом потоков) на веб-сервере, это как писать весь РНР код в одном файле.
Если вы имеете ввиду продолжение работы после формирования ответа на запрос — это в РНР есть и даже двумя способами -пул функций исполняемых перед завершением процесса и принудительное формирование ответа с закрытием сокета, первое удобно использовать в подключаемых библиотеках т.к. можно не напрягать пользователя библиотеки ручным завершением работы, второе удобно использовать в приложении.
Выполнять отложенные задачи создавая ещё один поток (или пользуясь пулом потоков) на веб-сервере, это как писать весь РНР код в одном файле.
Если вы имеете ввиду продолжение работы после формирования ответа на запрос — это в РНР есть и даже двумя способами -пул функций исполняемых перед завершением процесса и принудительное формирование ответа с закрытием сокета, первое удобно использовать в подключаемых библиотеках т.к. можно не напрягать пользователя библиотеки ручным завершением работы, второе удобно использовать в приложении.
1. пхп — не сервер
2. пользоваться пулом потоков для отложенных задач — моветон? с каких пор?
3. «перед завершением процесса» — вы серьёзно не видите проблем в таком решении?
Простите, но Вы очень похожи в своих суждениях на человека который ползуется костылями и реально считает, что это так и должно быть.
2. пользоваться пулом потоков для отложенных задач — моветон? с каких пор?
3. «перед завершением процесса» — вы серьёзно не видите проблем в таком решении?
Простите, но Вы очень похожи в своих суждениях на человека который ползуется костылями и реально считает, что это так и должно быть.
А вы очень похожи на человека который никогда на РНР не писал, но не одобряет
1 — РНР-fpm если не сервер то что тогда?
2 — да, отложенные задачи гонять на сервере приложений это моветон, смотрите сами:
* раз задачу можно отложить, значит для ответа на запрос она не нужна, тогда почему её обслуживает веб-сервер
* часто откладывают ресурсоёмкие задачи, однако у ресурсоёмких задач могут быть другие требования к програмному окружению и настройкам среды — зачем веб серверу в зависимостях ffmpeg?
* откладывают задачи потому что медленные, при росте сервиса это первый кандидат на дешёвое горизонтальное масштабирование, если у вас это в веб-сервер не встроено конечно
3 — Посмотрите как РНР работает, он «умирает» после каждого соединения, можно конечно сказать что это неоптимально, но многие задачи так решаются гораздо эффективнее, например можно значительно реже вызывать GC и не бояться что память исчезнет, ну и Erlang стоит упомянуть где эта штука возведена в абсолют
1 — РНР-fpm если не сервер то что тогда?
2 — да, отложенные задачи гонять на сервере приложений это моветон, смотрите сами:
* раз задачу можно отложить, значит для ответа на запрос она не нужна, тогда почему её обслуживает веб-сервер
* часто откладывают ресурсоёмкие задачи, однако у ресурсоёмких задач могут быть другие требования к програмному окружению и настройкам среды — зачем веб серверу в зависимостях ffmpeg?
* откладывают задачи потому что медленные, при росте сервиса это первый кандидат на дешёвое горизонтальное масштабирование, если у вас это в веб-сервер не встроено конечно
3 — Посмотрите как РНР работает, он «умирает» после каждого соединения, можно конечно сказать что это неоптимально, но многие задачи так решаются гораздо эффективнее, например можно значительно реже вызывать GC и не бояться что память исчезнет, ну и Erlang стоит упомянуть где эта штука возведена в абсолют
1. а с чего вдруг php-fpm = php? Вы сказали пхп сервер, а я вам намекнул что это не так. И вообще-то php-fpm не нужен чтоб написать веб сервер, даже на php.
2. если нет нужды в шаринге кешей, то я не вижу причин использовать сторонние утилиты, вместо встроенных очередей например в play2.
3. например в symfony2 кэш классов и конфигураций, а также php apc/opcache — это всё былоб не нужно, еслиб не умирал php. Инициализация окружения убивает скорость. Проще умирать? Конечно проще… Но с таким подходом, место php на домашних страничках не более. Ибо если проект взлетит, проблем не оберётесь.
P.S.
marcjschmidt.de/blog/2014/02/08/php-high-performance.html
habrahabr.ru/post/220393
2. если нет нужды в шаринге кешей, то я не вижу причин использовать сторонние утилиты, вместо встроенных очередей например в play2.
3. например в symfony2 кэш классов и конфигураций, а также php apc/opcache — это всё былоб не нужно, еслиб не умирал php. Инициализация окружения убивает скорость. Проще умирать? Конечно проще… Но с таким подходом, место php на домашних страничках не более. Ибо если проект взлетит, проблем не оберётесь.
P.S.
marcjschmidt.de/blog/2014/02/08/php-high-performance.html
habrahabr.ru/post/220393
fastcgi_finish_request?
Зачем вам прокси класс? Есть как минимум две DI для РНР не использующие прокси классов.
Да я и не обижаюсь. Иногда мне не хватает статики в PHP… это единственное что меня в языке смущает. но PHP7 движется в правильном направлении.
странно, что ещё никто не запостил.
Бла-бла-бла. Очередной холивор. А кто-нибудь ответит на вопрос как решаются задачи параллелизма на PHP?
Ну это удар ниже пояса. Хотя я раз за разом вижу как они гордятся своим костылями. И оно таки да! Заслуживает гордости ибо умудряется работать.
Ирония в том, что правильного ответа на этот вопрос нет. PHP — язык, для решения другого рода задач. Нет ничего лучше PHP, для решения задач разработки персональных страниц, форумов, простеньких интернет-магазинов, все эти задачи избыточно решать на том же С, или Java. Но и PHP ставить в ряд с Ruby, Python и уж тем более с C, Java, .NET (C#) — просто глупо.
Наблюдаю краем глаза за лавинообразным развитием пхп последних лет, и сделал парадоксальный вывод. Чем быстрее пхп развивается, тем быстрее он умрет. Очень просто. Из него сделают недо-яву (без юникода, потоков, толковой типизации, тормозную, с «шумным» синтаксисом), и люди получат больше оснований сравнивать.
А сравнив, сделают очевидный вывод.
Процесс запущен.
Мой прогноз: пхп умрет, когда отменят доллар в имени переменных.
А сравнив, сделают очевидный вывод.
Процесс запущен.
Мой прогноз: пхп умрет, когда отменят доллар в имени переменных.
> Мой прогноз: пхп умрет, когда отменят доллар в имени переменных
Т.е. никогда, так как синтаксис языка не позволит это сделать, да и не нужно это никому.
Т.е. никогда, так как синтаксис языка не позволит это сделать, да и не нужно это никому.
Почему не позволит? Вот заменили array() -> [] тоже все удивлялись.
Что такого принципиально невозможного? Почему в куче языков возможно, а в пхп нет?
Что такого принципиально невозможного? Почему в куче языков возможно, а в пхп нет?
Потому что доллар, хоть и не совсем красиво, но это удобно:
1) Сразу видно где переменная, а где константное значение (константа, дефайн, структура)
2) Позволяет объявлять одинаковые имена для полей, методов и констант
3) Позволяет экспортировать переменную из строковых значений ($$var)
4) Позволяет не конфликтовать с именами функций и классов (т.е. иметь строгость в отношении их переопределения, как минимум)
5) Позволяет отделять ключевые слова от имён переменных (например создать переменную с именем $class)
6) Позволяет интерполировать переменные без лишних спец.символов (это уже Bad Manners, но всё же фича языка)
Убирая доллары из языка потери по функциональности будут в разы больше, чем просто привычка видеть переменные без долларов.
1) Сразу видно где переменная, а где константное значение (константа, дефайн, структура)
2) Позволяет объявлять одинаковые имена для полей, методов и констант
3) Позволяет экспортировать переменную из строковых значений ($$var)
4) Позволяет не конфликтовать с именами функций и классов (т.е. иметь строгость в отношении их переопределения, как минимум)
5) Позволяет отделять ключевые слова от имён переменных (например создать переменную с именем $class)
6) Позволяет интерполировать переменные без лишних спец.символов (это уже Bad Manners, но всё же фича языка)
Убирая доллары из языка потери по функциональности будут в разы больше, чем просто привычка видеть переменные без долларов.
Бывает удобно — иногда, а некрасиво — всегда.
Понятно, что можно найти тысячу оправданий несовершенству парсера. Туда же ::, \, -> и прочие.
Понятно, что можно найти тысячу оправданий несовершенству парсера. Туда же ::, \, -> и прочие.
Что вас смущает в красоте?
По мне так код выглядит лучше чем во многих других языках
Когда мне приходиться писать на Java, мне не нравится как выглядит код
Но это дело вкуса и привычки
По мне так код выглядит лучше чем во многих других языках
Когда мне приходиться писать на Java, мне не нравится как выглядит код
Но это дело вкуса и привычки
Двойное двоеточие позволяет визуально определить где обращение к объекту, а где вызов статики:
$some::method(); // Сразу понятно, что $some — это строка с именем класса
$some->method(); // Очевидно, что это метод объекта $some
Чтоб обосновать выбор стрелочки в качестве доступа к объектам — надо пойти чуть глубже: Распространённая практика использования символа "+" для конкатенации строковых значений. Это вполне приемлемо, когда у нас статическая типизация, но в случае с динамической типизацией — подобный оператор может вызвать «подгорание стула» при сложении разных типов (JS тому доказательство). Надо было вводить новый оператор — была выбрана точка, чтоб избежать конфликтов. Для объектов стрелочка была именно потому, что точка уже занята и точно такой же оператор есть в C++, который выполняет практически тоже самое.
Обратный слеш был выбран просто потому, что изначально, в PHP 6 (который так и не вышел, частично переродившись в 5.3) был другой синтаксис (вроде бы двоеточие), но его исключили из-за каких-то возможных конфликтов. Эту информацию точно так же можно найти в интернете.
Если подытожить: Лично я считаю, что в PHP самый читаемый синтаксис из всего того, что я видел. Каждый символ, отличающийся от [a-z0-9_] выполняет только одну операцию и не длиннее 2х символов, в результате можно запросто определять лишь по одной строчке кода где и что хранится, а в языках с динамической типизацией это актуально более чем. Единственным спорным моментом, который бы я поправил в синтаксисе — это тернарный оператор, благодаря которому пришлось изобретать новые («a = b? c: d», «a = b ?: d» и «a = b ?? d»). Ну и добавить возможность опускать `function`.
$some::method(); // Сразу понятно, что $some — это строка с именем класса
$some->method(); // Очевидно, что это метод объекта $some
Чтоб обосновать выбор стрелочки в качестве доступа к объектам — надо пойти чуть глубже: Распространённая практика использования символа "+" для конкатенации строковых значений. Это вполне приемлемо, когда у нас статическая типизация, но в случае с динамической типизацией — подобный оператор может вызвать «подгорание стула» при сложении разных типов (JS тому доказательство). Надо было вводить новый оператор — была выбрана точка, чтоб избежать конфликтов. Для объектов стрелочка была именно потому, что точка уже занята и точно такой же оператор есть в C++, который выполняет практически тоже самое.
Обратный слеш был выбран просто потому, что изначально, в PHP 6 (который так и не вышел, частично переродившись в 5.3) был другой синтаксис (вроде бы двоеточие), но его исключили из-за каких-то возможных конфликтов. Эту информацию точно так же можно найти в интернете.
Если подытожить: Лично я считаю, что в PHP самый читаемый синтаксис из всего того, что я видел. Каждый символ, отличающийся от [a-z0-9_] выполняет только одну операцию и не длиннее 2х символов, в результате можно запросто определять лишь по одной строчке кода где и что хранится, а в языках с динамической типизацией это актуально более чем. Единственным спорным моментом, который бы я поправил в синтаксисе — это тернарный оператор, благодаря которому пришлось изобретать новые («a = b? c: d», «a = b ?: d» и «a = b ?? d»). Ну и добавить возможность опускать `function`.
Двойное двоеточие позволяет визуально определить где обращение к объекту, а где вызов статики:
А здесь обращение к объекту или к статике?
class OtherClass extends MyClass
{
public function myFunc()
{
parent::myFunc();
echo "OtherClass::myFunc()\n";
}
}
А т.ж.
So, word of warning: apparently, some PHP installations will let you use a $instance::method(), while others don't.
Ну и зачем оно нужно было чтоб потом юзвери путались что им писать?
Чтоб обосновать выбор стрелочки в качестве доступа к объектам — надо пойти чуть глубже: Распространённая практика использования символа "+" для конкатенации строковых значений.
Это все понятно. Череда обратных совместимостей породила монстра. Нет, обратная совместимость, безусловно, нужна. Даже важнее чем новые фичи. Но Вы же сами оголяете противоречие. С одной стороны Вы говорите, что синтаксис был обусловлен уже существующими конструкциями языка, и с другой пишете что вам полученный синтаксис нравится даже больше. Совпадение? Возможно. Но больше похоже на оправдание.
> А здесь обращение к объекту или к статике?
Возможно два варианта:
1) parent — это не переменная (там нет доллара), а обращение к родителю из текущего контекста (в данном случае из метода инстанса), а следовательно не должно быть и исключений из правил.
2) Начиная с какой-то там версии к статическим методам больше нельзя (на словах) обращаться через "->" и наоборот. PHP до сих пор позволяет это делать, но выкидывает то ли варнинг, то ли ошибку, мол «очень плохо». Вполне возможно, что эта конструкция осталась со времён, когда это было нормальным. Именно об этом и гласит строчка про варнинг (скорее всего), что в некоторых конфигах и версиях PHP ошибки могут подавляться и вызов возможен.
Итог: Возможно хорошим решением было бы добавление переменной "$parent->". Но вполне возможно это просто избыточно. Но замечание отличное, я об этом не подумал как-то даже.
> Это все понятно. Череда обратных совместимостей породила монстра.
Объекты со стрелочками были в C++ начиная с древнейших времён, никому оно не мешало, ну и php-сообществу тоже не особо (мне в том числе). Привычно, удобно, всё видно. И нет, не совпадение, а дальновидность дизайнеров языка, которой я поражаюсь. Но естественно всего предусмотреть нельзя. Думаю стоит посмотреть вот этот доклад, довольно интересный: www.youtube.com/watch?v=CX_K1r0Vklg (хоть он и о Java, но даёт представление о том, с чем сталкиваются проектировщики)
Возможно два варианта:
1) parent — это не переменная (там нет доллара), а обращение к родителю из текущего контекста (в данном случае из метода инстанса), а следовательно не должно быть и исключений из правил.
2) Начиная с какой-то там версии к статическим методам больше нельзя (на словах) обращаться через "->" и наоборот. PHP до сих пор позволяет это делать, но выкидывает то ли варнинг, то ли ошибку, мол «очень плохо». Вполне возможно, что эта конструкция осталась со времён, когда это было нормальным. Именно об этом и гласит строчка про варнинг (скорее всего), что в некоторых конфигах и версиях PHP ошибки могут подавляться и вызов возможен.
Итог: Возможно хорошим решением было бы добавление переменной "$parent->". Но вполне возможно это просто избыточно. Но замечание отличное, я об этом не подумал как-то даже.
> Это все понятно. Череда обратных совместимостей породила монстра.
Объекты со стрелочками были в C++ начиная с древнейших времён, никому оно не мешало, ну и php-сообществу тоже не особо (мне в том числе). Привычно, удобно, всё видно. И нет, не совпадение, а дальновидность дизайнеров языка, которой я поражаюсь. Но естественно всего предусмотреть нельзя. Думаю стоит посмотреть вот этот доклад, довольно интересный: www.youtube.com/watch?v=CX_K1r0Vklg (хоть он и о Java, но даёт представление о том, с чем сталкиваются проектировщики)
И нет, не совпадение, а дальновидность дизайнеров языка, которой я поражаюсь.
Блин ну в чем дальновидность-то?
Может быть в этом? (за достоверностью цитаты к автору поста)>>
Вместо этого Рамус Лердорф говорит вещи навроде:
У нас есть защищённые свойства, абстрактные методы, вся эта фигня, про которую ваш учитель информатики вам рассказывал. Мне на всё это дерьмо плевать.
Или в этом:
Хозяйке на заметку: PHP в линейном массиве из int-ов отводит где-то по 70-80 байт на элемент.
david-m.livejournal.com/1117497.html
Расмус — _один_из_ разработчиков, а не разработчик. Он придумал, но не он проектирует. Вот список современных контрибютеров: github.com/php/php-src/graphs/contributors До того, как был гитхаб — тоже Расмус был не одним единственным, и история названия Zend подтверждает мои слова.
> Или в этом:
Прошу прощения, а про какой массив говорится [] или SplFixedArray? Или наследники ArrayObject? Подозреваю, что про первый, хотя это не указано.
В таком случае ещё один вопрос — про какую версию говорится? PHP 4? PHP-FI 2? Судя по дате — 2009 год — это какая-то очень древняя версия, 4-ая (на дворе 2015 и летом выход 7-ой).
Или c Вашей стороны это намёк на скорость PHP? Ну в таком случае предлагаю посмотреть хотя бы на синтетику PHP 7.0 + Jit — gist.github.com/dstogov/12323ad13d3240aee8f1#file-b-txt На практике Jit не попадёт в релиз 7.0, но даже без него PHP всё равно быстрее всех существующих аналогов (яп с динамической типизацией).
К чему всё это?
> Или в этом:
Прошу прощения, а про какой массив говорится [] или SplFixedArray? Или наследники ArrayObject? Подозреваю, что про первый, хотя это не указано.
В таком случае ещё один вопрос — про какую версию говорится? PHP 4? PHP-FI 2? Судя по дате — 2009 год — это какая-то очень древняя версия, 4-ая (на дворе 2015 и летом выход 7-ой).
Или c Вашей стороны это намёк на скорость PHP? Ну в таком случае предлагаю посмотреть хотя бы на синтетику PHP 7.0 + Jit — gist.github.com/dstogov/12323ad13d3240aee8f1#file-b-txt На практике Jit не попадёт в релиз 7.0, но даже без него PHP всё равно быстрее всех существующих аналогов (яп с динамической типизацией).
К чему всё это?
Ясно, спасибо. Только как всё это дело относится к дизайну языка?
Очевидно, как. Додуматься впихнуть список и словарь в одну структуру — «гениальное» дизайнерское решение.
Это скорее архитектурное, а не дизайнерское решение. Вы путаете понятия. Я ещё раз кину ссылку на видеоролик в ютубе: www.youtube.com/watch?v=CX_K1r0Vklg на который я уже ссылался несколькими комментариями выше. Стоит всё же найти время и посмотреть его.
Если совсем кратко, то дизайн языка — это «как получать», а не «что получать». Небольшая капелька декларативности так сказать.
Если совсем кратко, то дизайн языка — это «как получать», а не «что получать». Небольшая капелька декларативности так сказать.
На моей памяти умерло два отличных инструмента своего времени Clipper и Delphi и единственной причиной этому стало прекращение развитие самого инструмента. Думаю то же самое можно утверждать и о Perl.
К примеру, Clipper так и не смог вовремя перепрыгнуть на SQL БД, не смог предложить RAD систему создания приложений. В результате, другие инструменты просто заменили его.Та же история произошла и в Delphi
Проблем с застоем в PHP пока не наблюдается, сообщество и разработчики постоянно шевелятся и обновляют как сам инструмент так и вспомогательную инфраструктуру регулярно.
Все остальное от лукавого.
К примеру, Clipper так и не смог вовремя перепрыгнуть на SQL БД, не смог предложить RAD систему создания приложений. В результате, другие инструменты просто заменили его.Та же история произошла и в Delphi
Проблем с застоем в PHP пока не наблюдается, сообщество и разработчики постоянно шевелятся и обновляют как сам инструмент так и вспомогательную инфраструктуру регулярно.
Все остальное от лукавого.
PHP — это дно, не идите люди в PHP, потом не выберетесь из этого дерьма.
Я работал с пхп-шниками, и честно говоря, они мне вы##ли мозг своей тупостью. Большинство из них не имеют ни малейшего представления о разработке ПО.
Это не удивительно, ведь многие из них начинали с создания сайтиков на джумле/вордпрессе/самописном г-движке.
Собственно, то что они сейчас делают, трудно назвать ПО. Гонятся за модными фреймворками, не имея при этом фундаментальных знаний в области разработки. В общем, в этой среде трудно стать настоящим профессионалом.
Я работал с пхп-шниками, и честно говоря, они мне вы##ли мозг своей тупостью. Большинство из них не имеют ни малейшего представления о разработке ПО.
Это не удивительно, ведь многие из них начинали с создания сайтиков на джумле/вордпрессе/самописном г-движке.
Собственно, то что они сейчас делают, трудно назвать ПО. Гонятся за модными фреймворками, не имея при этом фундаментальных знаний в области разработки. В общем, в этой среде трудно стать настоящим профессионалом.
Не услышал ни одного нормального довода, да и главное, что же лучше, если автор говорит что пхп устарел, то, что же тогда новое и мощное и хорошее должно придти на замену?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему PHP устарел