Попробую ответить за вашего визави. Реальный случай из жизни, причём, совсем не «за новые формочки», а хоть бы как-то заставить работать.
Купили на СТО железку для общения с тем, что в автомобилях 90-х называется «компьютером». К нему прилагается софт, по внешнему виду писанный ещё во времена, когда в моде были контролы Win3.x-style. Всё это добро ещё работает на WinXP, но уже в момент, когда его купили WinXP не продавался, а все ноуты шли с Вистой.
Конечно, было два пути решения — искать б/у ноут или пиратить винду, но это ведь тоже решения тянущие в дремучее прошлое — ноуты ломаются, нелицензионка на предприятии — к добру не ведёт.
При этом производитель железа на тот момент явно испытывал сильную зубную боль от самой идеи переписывания ПО (ассортимент железок большой, рынок — не так уж и велик, кризис, опять же).
Так что, ниша, из-за устаревания систем и прекращения поддержки, наверно, всё-таки есть.
Фишка Rust в том, что он выносит приличную долю ловли блох на этап компиляции, а не отладки. У кого-то это создаёт впечатление сложности самого языка, который тяжело заставить собрать программу. Но на практике это означает лишь то, что программист, мнящий, что он ЗНАЕТ все входы и выходы в своей программе, на самом деле тешит себя в иллюзиями и будет собирать эти грабли чуть позже на этапе закрытия тяжелоуловимых багов, возможно вместо выходных, поскольку упало именно на продакшене и закрыть период нужно было ещё вчера.
Что ж, я так понимаю, в ближайшее время мы будем наблюдать захватывающий этап становления нескольких достойных языков, каждый из которых предлагает свой компромисс между простотой и дисциплиной и каждый по своему нацеленных на продуктивность.
Не знаю, как на Ruby, но на том же Python местами приходится «комментировать» код нездоровым количеством ассертов, которые перегружают реализацию, выполняется двойная и тройная работа, продуктивность серьёзно проседает. Да, гибкость, за которую многое можно отдать. Но в крупном проекте — сложность растёт в итоге не только от сложности самого проекта и цена выходит за всякие разумные рамки, так что даже IDE тебя начинает посылать, приходится от «гибкости» отказываться везде, где действительно можно обойтись без неё — приходит просветление и трансцендентное осознание концепции KISS.
У некоторых IDE (не будем показывать пальцем в лидеров индустрии) вообще странная мания ломать отступы при вставке из буфера. Со скобками в этом плане проще — код автоматом форматируется по скобкам.
Для этого наверно нужно действительно подождать появления Rust-style кода. Можно попробовать не разворачивать итераторы в for — не будет такого давления вложенностями. Rust действительно обеспечивает «нулевую стоимость абстракций» и их не стоит бояться. Но для всего этого нужен опыт, с которым пока туго — язык молодой и до сих пор сильно менявшийся.
Это примерно как и с питоном — можно сесть и сразу написать по опыту программирования на другом языке какое-нибудь решение в лоб и оно будет относительно неплохо работать. Но проходит время, набирается опыт, меняется стиль, и со временем обнаруживаешь, что писать на питоне можно значительно понятней и компактней.
На днях исправлял в вики примеры кода 2013-го года на актуальные. Местами Rust стал значительно компактней.
Вот мне кажется в этом направлении и стоит иногда задумываться. А почему так стремятся, например, миновать спинной мозг и подключить управление к головному мозгу? Ну, понятно, в статьях часто речь идёт об экспериментах с парализованными больными, возвращении утраченного зрения, слуха, у которых именно «интерфейсное» звено дало сбой.
Но для практических целей в общем может оказаться эффективней подключаться где-то на участках, управляющих мышцами, или работающих с аудио-видео сигналом — это может оказаться эффективней, например, для виртуальной клавиатуры или будущего аналога мыши.
Ну и, вероятно, со временем таки подберёмся к решению задачи эффективного создания-выращивания таких интерфейсов, по аналогии с имеющимися.
Он везде буферизован, но дело не в этом — просто «положить результат в лукошко» или таки запустить целую функцию, которая делает явно больше, чем собирает результат (например, конвертация числа в строку, что для больших чисел уже «длинная» операция, и положить уже этот распухший результат в буфер).
> В таком случае думаю стоит именно его противопоставлять Symfony, а не монолитный Django. Разве нет?
Противопоставлять нужно всю компонентную базу PHP и Python, смысл выхватывать один Symphony? Из ZF тоже можно неплохо дёргать компоненты. Остальные библиотеки решающие частные задачи — можно воспринимать как немного более сложные компоненты — всему требуется та или иная адаптация в рамках своей «солянки».
Но в этом случае не получится сказать, что PHP богаче Python. Скорее наоборот — изначально модульный Python богаче, поскольку любой более менее общий код, который возможно использовать повторно, оформляется как общая библиотека, а не как компонент какого-то конкретного фреймворка и может быть легко подключён/использован. И так же изначально перед Python ставились более «серьёзные» задачи, экосистема языка протирается в глубины OS, в дебри научных исследований, на высоты обработки «больших данных». Было время я писал фоновые обработчики задач на PHP, поскольку веб-часть уже была на PHP, но Python постепенно всё вытеснил, поскольку «демоны» на нём значительно надёжнее и удобнее, библиотеки «суровее», постепенно он занял своё достойное место как язык встроенных процедур в базе данных. И постепенно назрела необходимость отказаться от двуязычия и перевести на Python и веб-часть.
И нужно признать, что Python, возможно не самый идеальный язык. Но именно если сравнивать его с PHP при решении задач в растущем бизнесе — PHP с усложнением проекта теряет все свои преимущества, а его недостатки выпирают всё сильнее.
Багрепорт и последующая переписка, конечно, фееричны, но почему Вы отождествляете Lawrence Krubner (автор статьи) и кого-либо из персонажей разыгравшейся в багтрекере драмы?
По совокупности скорости/стоимости разработки и производительности 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, место ему только в музее — мир всё сложнее и требовательнее.
А что с тех пор принципиально изменилось?
Можно спорить с тем, что язык устарел и непригоден, демонстрируя отличные кейсы его использования, но аргументы в статье сохраняют актуальность — новые версии не решают практически ничего из перечисленного.
«Человек культурный» — феномен по определению искусственный.
Если лишить человека образования и воспитания, он опускается на уровень «ещё одного вида обезьян».
Поэтому вопрос скорее не «если всё пустить на самотёк», а «какая система распространения культуры и образования» установится силами активных членов общества и сопротивления остальных.
Осознание обществом ценности той или иной культуры вещь весьма относительная и субъективная, и кроме всего прочего замкнута на воспитание.
То есть, если увеличить процент осознанных граждан, не просто мотивированных, но и владеющих технологией повышения осознанности, осознанно выбирающих культурные ценности, возможно мы достигнем качественного скачка, после которого падение доли успешых и эффективных людей станет возможным лишь в результате разрушения защищаемой обществом и традициями инфраструктуры образования и воспитания.
«Поэтому для бизнес-логики, как правило, не используют C/C++, а берут C# или Python, где в стандартной библиотеке уже встроен тип Decimal»
Как-то это слишком толсто. Выбор таких разных платформ только из-за присутствия некой функциональности в стандартной библиотеке, которая, кстати, туда попадает из более низкоуровневых библиотек? Вообще подобные утверждения как-то иррелевантны теме статьи, упомянуть о наличии таких встроенных средств в высокоуровневые языки можно без излишней «рационализации».
Не везде открывается. Вот в одно и то же время — у меня висит, пытается соединиться, а у товарища — прекрасно грузится. Возможно слишком параноидальный бот-фильтр у хостера? Мой провайдер характерен тем, что за несколькими белыми ip целый город сидит.
Купили на СТО железку для общения с тем, что в автомобилях 90-х называется «компьютером». К нему прилагается софт, по внешнему виду писанный ещё во времена, когда в моде были контролы Win3.x-style. Всё это добро ещё работает на WinXP, но уже в момент, когда его купили WinXP не продавался, а все ноуты шли с Вистой.
Конечно, было два пути решения — искать б/у ноут или пиратить винду, но это ведь тоже решения тянущие в дремучее прошлое — ноуты ломаются, нелицензионка на предприятии — к добру не ведёт.
При этом производитель железа на тот момент явно испытывал сильную зубную боль от самой идеи переписывания ПО (ассортимент железок большой, рынок — не так уж и велик, кризис, опять же).
Так что, ниша, из-за устаревания систем и прекращения поддержки, наверно, всё-таки есть.
Что ж, я так понимаю, в ближайшее время мы будем наблюдать захватывающий этап становления нескольких достойных языков, каждый из которых предлагает свой компромисс между простотой и дисциплиной и каждый по своему нацеленных на продуктивность.
github.com/rust-lang/rust/blob/master/src/doc/style/style/README.md
Это примерно как и с питоном — можно сесть и сразу написать по опыту программирования на другом языке какое-нибудь решение в лоб и оно будет относительно неплохо работать. Но проходит время, набирается опыт, меняется стиль, и со временем обнаруживаешь, что писать на питоне можно значительно понятней и компактней.
На днях исправлял в вики примеры кода 2013-го года на актуальные. Местами Rust стал значительно компактней.
Но для практических целей в общем может оказаться эффективней подключаться где-то на участках, управляющих мышцами, или работающих с аудио-видео сигналом — это может оказаться эффективней, например, для виртуальной клавиатуры или будущего аналога мыши.
Ну и, вероятно, со временем таки подберёмся к решению задачи эффективного создания-выращивания таких интерфейсов, по аналогии с имеющимися.
Противопоставлять нужно всю компонентную базу PHP и Python, смысл выхватывать один Symphony? Из ZF тоже можно неплохо дёргать компоненты. Остальные библиотеки решающие частные задачи — можно воспринимать как немного более сложные компоненты — всему требуется та или иная адаптация в рамках своей «солянки».
Но в этом случае не получится сказать, что PHP богаче Python. Скорее наоборот — изначально модульный Python богаче, поскольку любой более менее общий код, который возможно использовать повторно, оформляется как общая библиотека, а не как компонент какого-то конкретного фреймворка и может быть легко подключён/использован. И так же изначально перед Python ставились более «серьёзные» задачи, экосистема языка протирается в глубины OS, в дебри научных исследований, на высоты обработки «больших данных». Было время я писал фоновые обработчики задач на PHP, поскольку веб-часть уже была на PHP, но Python постепенно всё вытеснил, поскольку «демоны» на нём значительно надёжнее и удобнее, библиотеки «суровее», постепенно он занял своё достойное место как язык встроенных процедур в базе данных. И постепенно назрела необходимость отказаться от двуязычия и перевести на Python и веб-часть.
И нужно признать, что Python, возможно не самый идеальный язык. Но именно если сравнивать его с 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, место ему только в музее — мир всё сложнее и требовательнее.
Можно спорить с тем, что язык устарел и непригоден, демонстрируя отличные кейсы его использования, но аргументы в статье сохраняют актуальность — новые версии не решают практически ничего из перечисленного.
Если лишить человека образования и воспитания, он опускается на уровень «ещё одного вида обезьян».
Поэтому вопрос скорее не «если всё пустить на самотёк», а «какая система распространения культуры и образования» установится силами активных членов общества и сопротивления остальных.
Осознание обществом ценности той или иной культуры вещь весьма относительная и субъективная, и кроме всего прочего замкнута на воспитание.
То есть, если увеличить процент осознанных граждан, не просто мотивированных, но и владеющих технологией повышения осознанности, осознанно выбирающих культурные ценности, возможно мы достигнем качественного скачка, после которого падение доли успешых и эффективных людей станет возможным лишь в результате разрушения защищаемой обществом и традициями инфраструктуры образования и воспитания.
Как-то это слишком толсто. Выбор таких разных платформ только из-за присутствия некой функциональности в стандартной библиотеке, которая, кстати, туда попадает из более низкоуровневых библиотек? Вообще подобные утверждения как-то иррелевантны теме статьи, упомянуть о наличии таких встроенных средств в высокоуровневые языки можно без излишней «рационализации».