1) C – слишком сложный для часто меняющегося проекта. Компиляция занимала много времени, было мало свободных инструментов, а платные не влезали в мой бюджет. Слишком многословный. Управление зависимостями было сложным делом.
2) Java – лучше, чем С, но всё ещё многословный и долго компилирующийся. Управление зависимостями было сложным делом.
3) Perl – почти так же хорош, как PHP, только без системы управления пакетами. На CPAN был набор модулей на все случаи жизни, но их надо было скачивать и устанавливать. Управление зависимостями было сложным делом.
4) ASP – почти так же хорош, как PHP, только это был инструмент от Microsoft, и его использование засосало бы меня в их дорогой мир.
Для трёх позиций я написал: " Управление зависимостями было сложным делом". Для меня это был ключевой момент PHP. Его философия была «всё в одном». Таких, как сейчас, систем управления пакетами тогда не было. Сейчас есть удобные штуки типа Bundler для Ruby и Leiningen для Clojure. Но не в 2000-м. Даже системы управления пакетами в Linux стали лучше с 2000 года. А система «всё в одном» решала проблемы управления пакетами в PHP. Но теперь это преимущество не имеет значения.
У PHP есть и другие сильные стороны. Он оптимизирован для веба, но это сегодня не уникально. Для тех, кто боялся С, он предложил обёртки для функций С. Но в других языках сегодня всё ещё проще:
проблемы языка Julia в настоящее время – относительная нехватка библиотек. Но в языке достаточно просто взаимодействовать с существующими библиотеками из С. В отличие от других языков, вы можете вызывать код С, не написав ни строчки на С, и поэтому я думаю, что библиотеки для Julia быстро подтянутся. По моему опыту у меня получилось использовать 5 000 строк С-кода через 150 строк кода на Julia.
За последние несколько лет я работал в разных корпорациях (Wine Spectator, Timeout) над их системами. В основном это был PHP и фрейморк Symfony. Я уже критиковал их ранее. Мне кажется, что люди, использующие в корпоративных задачах PHP в наше время, забыли, почему PHP нравился им раньше. Можно рассказать, какие преимущества были у него в 2000 году, но сегодня? Он медленный, неуклюжий, системы стали слишком сложными, некомпилируемая сущность языка встаёт на пути попыток сделать на нём большие проекты. Если вы делаете CMS в проекте, которому нужны 100 серверов, вам придётся деплоить CMS целиком на каждый из 100 серверов.
Какие инновации в мире PHP существуют сегодня?
Люди добавляют pthreads, когда в языке нет инструментов для работы с параллелизмом. Для контраста взгляните на Clojure.
Сложная система кэширования кода у Symfony.
В комментарии добавляют аннотации – инструкции, контролирующие выполнение программы. Мне кажется, что это плохая идея. Если вам необходимо моделировать взаимодействующие проблемы (cross-cutting concerns), вам нужно выбрать язык, который делает это элегантно, а не полагаться на сырое решение вроде аннотаций.
Список изменений и исправлений, которые необходимо сделать из-за длинной истории противоречивой разработки.
Разбухшее управление памятью.
Ритуальное программирование – куча ненужных инструкций, без преимуществ вроде проверки на этапе компиляции. В 2000 одним из аргументов в пользу PHP было то, что в нём не было лишнего кода, типичного для Java. Хотим ли мы, чтобы PHP полностью превратился в Java?
Любовь к сложности ради сложности.
Никаких настроек для управления и конфигурирования. Это похоже на отсутствие систем управления пакетами, от которого PHP страдал – в отличие от Ruby, Python или Clojure. Но в PHP не ведётся никакой работы по исправлению ситуации – это перекладывается на плечи инструментов сисадмина вроде Chef и Supervisor.
Обилие обезьяньих патчей (подмены методов и значений атрибутов классов программы во время ее выполнения). traits похожи на обезьяньи патчи в Ruby, но с traits ещё сложнее работать, а также отслеживать и отлаживать их.
Амбиции, обгоняющие сам язык. Как сказал Фабьен Потансье, у PHP есть несколько замечательных свойств. Что странно. Это как если бы мы вставили мощный движок от Ferrari в ржавый Fiat.
Бесконечное множество функций, введённых для удобства.
И не могу не вспомнить знаменитое эссе: "PHP: фрактал плохого дизайна".
Когда у PHP встречаются крутые штуки (Streams и Iterators), они получаются как бы прибитыми к языку, а не интегрированными в него. Они не ощущаются частью философии языка. Вместо этого Рамус Лердорф говорит вещи навроде:
У нас есть защищённые свойства, абстрактные методы, вся эта фигня, про которую ваш учитель информатики вам рассказывал. Мне на всё это дерьмо плевать.
Для сравнения, Юкихиро Мацумото описывает Ruby так:
Для меня часть смысла жизни состоит в радости. Программисты радуются, когда они могут сконцентрироваться на творческом аспекте программирования. Ruby разработан так, чтобы делать программистов счастливыми. Если вы делаете работу быстро и весело, это же хорошо, не так ли? Ваша жизнь становится лучше. Я хочу решать повседневные задачи при помощи компьютера, поэтому я пишу программы. Используя Ruby, я хочу концентрироваться на том, что я делаю, а не на волшебных правилах языка вроде необходимости начинать программу со слов «public void что-то что-то что-то» для того, чтобы потом сказать «print hello world».
Недостаток глубокого видения у лидеров команды разработчиков PHP ведёт к уродливым проявлениям, в частности, к отсутствию наставлений для начинающих программистов о том, как писать на PHP хороший код.
В 2004 году внезапно появился Ruby On Rails, и пообещал спасти всех от сложности Java и беспорядка PHP. В то время это было большое улучшение. В нём была структурированность и элегантность, недоступная PHP. Но сегодня даже Rails устарел. Сегодня Ruby и PHP одинаково плохо работают с паралеллизмом. Они разрабатывались тогда, когда у компьютерных процессоров было одно ядро, которое со временем становилось всё быстрее. Но будущее подчиняется закону Амдала, и в этом направлении им нечего предложить. jRuby – будущее Ruby, один из тех языков, которые сегодня стоит рассматривать. Но нет языка, про который можно было бы сказать «это будущее PHP».
Хотелось бы мне, чтобы люди могли ответить мне на вопрос «почему бы я сегодня выбрал для себя PHP?». В 2000 году аргументы за него были убедительными, но сегодня таких причин нет. Мир изменился, и сейчас есть десятки лучших возможностей.
Комментарии (165)
iGusev
26.05.2015 03:31+18January 23rd, 2014
Устаревшая статья об устаревании PHP
BlessMaster
26.05.2015 03:54+4А что с тех пор принципиально изменилось?
Можно спорить с тем, что язык устарел и непригоден, демонстрируя отличные кейсы его использования, но аргументы в статье сохраняют актуальность — новые версии не решают практически ничего из перечисленного.iGusev
26.05.2015 04:40+36Он медленный, неуклюжий
По совокупности скорости/стоимости разработки и производительности 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 плохой.»BlessMaster
26.05.2015 07:04+9По совокупности скорости/стоимости разработки и производительности 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, место ему только в музее — мир всё сложнее и требовательнее.
Crandel
26.05.2015 10:08+3согласен с аргументами, пока не перейдешь на другой язык, не поймешь всю глубину неудобства php. Лично мне на python гораздо удобнее разрабатывать крупные проекты
ApeCoder
26.05.2015 10:33А чем php удобнее python для маленьких проектов? Легче найти дешевых программеров и дешевый хостинг? Куча готового кода на все вебслучаи жизни?
Crandel
26.05.2015 10:42+2я не говорил, что php удобнее для маленьких проектов, просто последние полгода у меня только большие проекты, а для маленьких вполне можно flask взять или любой другой микрофреймворк. Быстро, удобно и ничего лишнего и главное очень легко читаемый код для тех, кто будет сопровождать
Regis
26.05.2015 10:51-3На маленьких проектах меньше заметна разница. Про дешевизу — согласен. Про готовый код — пожалуй у того же питона побольше будет.
OnYourLips
26.05.2015 11:34+2Перешел с python на PHP (и Ruby on Rails параллельно использую для периодических заказов, основным требованием которых является скорость разработки).
Считаю, что PHP из этих вариантов более перспективен, быстрее развивается и гораздо лучше подходит для крупных проектов.
Сам синтаксис у python конечно же изящнее, но экосистема важнее синтаксиса.ApeCoder
26.05.2015 12:00+2А нельзя ли развить мысль более аргументированно с примерами?
OnYourLips
27.05.2015 16:15+1Большинство минусов PHP опровергли в комментарии выше.
А лучше PHP например тем, что на нем есть Symfony.
Аналогов в Python и Ruby не видел.
И PHP 7 движется в этом направлении: теперь есть строгий статический контроль типов.
Естественно есть аналоги на Java или C# (Spring, ASP.NET MVC и т.д.), но эти языки уже в другой крайности, и писать на них что-то требовательное к скорости разработки не выйдет.
А PHP можно применять в обоих этих областях.Crandel
27.05.2015 16:22-1Django на голову превосходит симфонию, а по настройке так вообще с ней ничто не сравнится с мира пыха
SerafimArts
27.05.2015 17:19+1Т.е. я могу установить отдельно только пакет кеширования из Django (он ведь там есть) и использовать вместе, например, с каким-нибудь самописным решением? А то я вижу в репозитории (https://github.com/django/django/tree/master/django/core/cache) всё в куче, как делали в PHP года 2-3 назад. Например кеш в симфони (точнее доктрины): github.com/doctrine/cache
Crandel
27.05.2015 17:26-1если нужна модульность, пожалуйста, берите Flask и лепите все, что душе угодно
habrahabr.ru/post/251415SerafimArts
27.05.2015 17:41+1Смысл Симфони в том, что он одновременно и модульный до безобразия, и исходники там практически идеальные, и при этом имеет стандартное приложение (тоже отдельный компонент), который объединяет все эти компоненты в одно единое, и это не микрофреймворк.
Если что-либо приходится писать, какое-то легковесное приложение — проще всего вместо всего фрейма взять пару-тройку компонентов: Twig (шаблонизатор), HttpFoundation (удобная работа с Request -> Response), Doctrine Cache и просто собрать нужное. При этом можно быть на 99.9% уверенным, что там нет никаких ошибок. Например такие фреймворки, как Laravel, Lumen, Slim процентов на 30-50 состоят из его компонентов.
Ну и к тому же оно ставится одной строчкой: `composer install symfony/finder 2.5.*` (поставить в проект компонент работы с поиском файлов в ФС версии 2.5).Crandel
27.05.2015 17:50+1не вижу принципиальной разницы
pip install flask-*
еще проще в установке.
а вот virtualenvwrapper позволяет поставить все сторонние библиотеки в любое место на жестком диске, не ограничиваясь папкой vendors
а вот постоянное удаление composer.lock при разработке в большой команде очень сильно раздражалоSerafimArts
27.05.2015 17:57> а вот постоянное удаление composer.lock при разработке в большой команде очень сильно раздражало
composer.lock удалять нельзя — это список текущих установленных вендоров для того, чтоб при выполнении `composer install` на продакшене поставились именно эти версии (до самой минорной версии) пакетов, которые установлены локально, один-в-один. Для того, чтоб проигнорировать его и обновить все зависимости (с перезаписью lock-файла) есть команда `composer update`. И это всё есть в документации — первые абзацы.
> а вот virtualenvwrapper позволяет поставить все сторонние библиотеки в любое место на жестком диске, не ограничиваясь папкой vendors
Запустить композер с флагом `-g` для установки глобально или прописать в composer.json `vendor-dir` для указания каталога, куда нужно поставить всё (не в дефолтную папочку vendor)
> не вижу принципиальной разницы
pip install flask-*
еще проще в установке.
В таком случае думаю стоит именно его противопоставлять Symfony, а не монолитный Django. Разве нет?Crandel
27.05.2015 20:37да, по поводу фласка вы правы
SerafimArts
27.05.2015 21:15В таком случае флакс — это микрофреймворк, сравнимый разве что со Slim или Lumen. А Symfony — это fullstack фреймворк, включающий в себя начиная с обычного MVC + Роутинг, заканчивая ОРМ и абстракцией над файловой системой.
Сам язык — PHP, имеет такую мощную штуку, как интерфейсы, которые позволяют реализовывать надёжный полиморфизм (если так можно выразиться). Благодаря чему хороший код на PHP всегда будет лучше кода языков, где нет инструмента, обеспечивающего гарантию полной реализации класса, например абстрактные классы (помимо интерфейсов). Тоже можно сказать и о явной инкапсуляции. Параллель можно провести с динамически-типизированными и статически-типизированными языками — второй вариант будет надёжнее и качественнее по вполне очевидным причинам.
Я не столь хорошо знаю питон, что бы утверждать что-то наверняка, но по-моему при сравнении абстрактного качества исходного кода в вакууме и пользуясь логикой из второго абзаца — вывод о том, что код на питоне более привлекателен и даже приводить в пример монолитный каркас, как доказательство — слишком уж опрометчиво. Вы не находите?Crandel
27.05.2015 21:24для меня более привлекателен именно код на питоне и использование джанги для больших проектов. кому нужны маленькие, могут выбирать фласк и строить и з него мелкие сайты. я полтора года пользовался симфони и после перехода на питон/джанго вздохнул с огромным облегчением. Для меня лично — php ужасный и неудобный язык, наполненный костылями и я очень рад, что поменял его на python
BlessMaster
29.05.2015 22:49> В таком случае думаю стоит именно его противопоставлять Symfony, а не монолитный Django. Разве нет?
Противопоставлять нужно всю компонентную базу PHP и Python, смысл выхватывать один Symphony? Из ZF тоже можно неплохо дёргать компоненты. Остальные библиотеки решающие частные задачи — можно воспринимать как немного более сложные компоненты — всему требуется та или иная адаптация в рамках своей «солянки».
Но в этом случае не получится сказать, что PHP богаче Python. Скорее наоборот — изначально модульный Python богаче, поскольку любой более менее общий код, который возможно использовать повторно, оформляется как общая библиотека, а не как компонент какого-то конкретного фреймворка и может быть легко подключён/использован. И так же изначально перед Python ставились более «серьёзные» задачи, экосистема языка протирается в глубины OS, в дебри научных исследований, на высоты обработки «больших данных». Было время я писал фоновые обработчики задач на PHP, поскольку веб-часть уже была на PHP, но Python постепенно всё вытеснил, поскольку «демоны» на нём значительно надёжнее и удобнее, библиотеки «суровее», постепенно он занял своё достойное место как язык встроенных процедур в базе данных. И постепенно назрела необходимость отказаться от двуязычия и перевести на Python и веб-часть.
И нужно признать, что Python, возможно не самый идеальный язык. Но именно если сравнивать его с PHP при решении задач в растущем бизнесе — PHP с усложнением проекта теряет все свои преимущества, а его недостатки выпирают всё сильнее.
webkumo
26.05.2015 16:37Вот просто интересно… здесь все спорят какой скриптовой язык лучше… Постараюсь выделиться:
— если экосистема важнее — то почему не Java? Чем экосистема PHP лучше?iGusev
26.05.2015 17:50-3Примерно поэтому
SerafimArts
27.05.2015 17:51+1Типичный процесс работы с Java: «Не хватает N компонента, пропишу-ка я в градле вот эту зависимость.». Остальной день тратится на то, чтоб подогнать объекты этого компонента к объектам уже существующего кода (если нет нормальных интерфейсов).
Типичный процесс работы с PHP: «Не хватает N компонента, пропишу-ка я в composer вот эту зависимость.». Остальной день тратится на то, чтоб выяснить внезапно появившиеся проблемы из-за его использования (если нет нормального покрытия тестами).
Конечно это всё ирония, но некоторая толика истины есть. В Java мне не нравится то, что каждый норовит реализовать свой объект для всех существующих в языке вещей, дополняя их, а потом дружить это всё довольно проблематично. В PHP — приходится зачастую исследовать исходники, чтоб понять хотя бы какие возможности есть и нормальный ли вообще код, можно ли его использовать.
Temirkhan
26.05.2015 15:31+1Хлопаю двумя руками: Вы уместили полноценный контрольный-ответ на статью в комментарий)
sectus
26.05.2015 05:39Список изменений и исправлений
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...BlessMaster
26.05.2015 07:32+2Багрепорт и последующая переписка, конечно, фееричны, но почему Вы отождествляете Lawrence Krubner (автор статьи) и кого-либо из персонажей разыгравшейся в багтрекере драмы?
bolk
26.05.2015 07:24+1Perl – почти так же хорош, как PHP, только без системы управления пакетами.
Да уж конечно. Сколько лет прошло, а я до сих пор помню команду perl -MCPAN -e shell < это и есть система управления пакетами.
ShadowsMind
26.05.2015 09:05Java – лучше, чем С, но всё ещё многословный и долго компилирующийся. Управление зависимостями было сложным делом.
Про многословность ладно — спорить нет смысла. А вот про управления зависимостями и время компиляции это что-то уж совсем клевета. Может быть просто я чего-то не знаю про те времена о которых говорит автор.
middle
26.05.2015 10:21Maven был не всегда.
Regis
26.05.2015 10:53Но ведь статья не настолько стара.
middle
26.05.2015 11:16Статья начинается со слов «В 2000 году ...», а в вашей же цитате присутствует слово «было» :)
ShadowsMind
26.05.2015 12:07Хм, тогда да — возможно были проблемы, т.к. Maven в 2002'ом появился, а Ivy и Gradle гораздо позже…
GrizliK1988
26.05.2015 09:14+6Прошу прощения, но помогите, пожалуйста, понять в чем цель данной статьи. В чем вообще цель статей, критикующих и только критикующих конкретный язык программирования/фреймворк?
Regis
26.05.2015 10:56Думаю, что с точки зрения автора — поделится опытом и предупредить.
А то мало ли, кто-то подумает изучать PHP или использовать его в новом проекте :)
Scrooge2
26.05.2015 10:04-9Статья правильная, аргументированная.
Мнение фанатов в счет принимать не стоит.
SerafimArts
26.05.2015 11:02+2Ну если уж JRuby — это будущее Ruby, то почему JPhp не может быть будущим PHP?
ShadowsMind
26.05.2015 12:19+1Впервые слышу про светлое будущее JRuby. Да и вообще разве у Ruby сейчас темное настоящее? )
А по поводу JPHP — а зачем, когда под JVM есть — Groovy, Scala, Ceylon, Kotlin etc.? Никогда не понимал людей, которые хотят писать под другие платформы/ниши, но при этом ленятся изучить новый язык.VolCh
26.05.2015 12:38Ну так основная ниша — веб-приложения — измениться от перехода на какой-нибудь JPHP не должна по идее
SerafimArts
26.05.2015 13:27-1Я тоже, признаться, первый раз слышу о том, что JRuby — это светлое будущее Ruby. Но так написано в предпоследнем абзаце данного поста.
А Groovy, Scala, Ceylon, Kotlin, etc — это строготипизированные языки, в отличие от PHP. JPhp — это не альтренатива ни им, ни Zend-Based PHP — там своё АПИ, более приятное, нежели у оригинала и возможности той же Java. Он идеально подходит для прототипирования, когда скорость приложения не важна (да и жаловаться на скорость работы JPhp странновато, он всё же быстрее PHP, включая даже 7ку), а объём кода важен. Учитывая возможность беспроблемно перейти на более низкий уровень — перспективы написания всяких приложенец для стартапов по-моему идеальны.
dim_s
26.05.2015 14:18Люди пишут на Groovy, Scala и т.д. не ради того, что они исполняются на JVM. Непонятно откуда пошел такой миф, что если человек использует JVM язык то ему в первую очередь нужен язык, который бы выполнялся на JVM. JVM это лишь удобная платформа для имплементации различных языков.
gkopanev
26.05.2015 11:18+4У PHP есть главное преимущество перед другими языками — сверхнизкая стоимость кода. Точнее — сверхнизкая стоимость решения с помощью кода реальных задач. Пока другие языки не смогут его в этом вопросе превзойти — никакие доводы не сдвинут его с пьедестала самого популярного языка программирования. Пока мы живем при капитализме — именно деньги решают, who is hot and who is not.
Crandel
26.05.2015 11:57+5вы так горды тем, что получаете самую низкую оплату за тот же объем работы среди всех программистов?
Rastishka
26.05.2015 12:31+1Да, в том числе и этим. Низкая себестоимость = высокие конкурентные преимущества на рынке как специалиста.
Более вероятно что буду востребован именно я, при сравнимой продуктивности.
Или вы предлагаете писать на брэйнфаке и гордиться какая дорогая разработка выходит?Crandel
26.05.2015 12:43я предлагаю писать на питоне, так как на нем скорость разработки в разы выше, а про сопровождение я вообще молчу. я без труда нашел себе работу за приемлимую оплату, которая выше чем у тимлида на предыдущей работе, связанной с разработкой на пыхе. и да теперь разработка крупных проектов происходит быстрее и разобраться в легаси намного легче. ИМХО
gkopanev
26.05.2015 12:56+1Возможно, что все именно так, как вы говорите, но рынок не подтверждает ваших выводов.
Нужно понимать, что именно рынок выбирает. Язык выбирает заказчик, а не программист. И заказчик чаще выбирает именно PHP. По целому ряду причин.
Разумеется PHP не идеален. Разумеется есть языки лучше, круче, удобнее.
Но также как на автомобильном рынке по продажам лидирует весьма спорная Лада, также и на рынке разработки лидирует PHP, который выбирали, выбирают и будут выбирать потому, что он «дешев и сердит».Crandel
26.05.2015 13:02+1я все равно не понимаю зачем умному программисту, который думает в первую очередь про выгоду для себя или своей семьи выбирать себе самую низкооплачиваемую работу, когда он может работать с большим удовольствием за лучшие деньги? Заказов на питоне/руби/node.js и тд. вполне хватает, так почему же ему выбирать самый неудобный инструмент(картинка_с_молотком.jpg)?
gkopanev
26.05.2015 13:16-1Если у программиста PHP работа будет всегда, пусть и с более низкой оплатой, то сможет ли специалист на node.js найти себе стабильную и высокооплачиваемую работу — это еще вопрос.
Люди покупали и будут покупать машины. Но в кризисные времена люди в первую очередь перестанут покупать Роллс-Ройсы и скорее купят Ладу. И продавец Роллс-Ройсов будет вынужден либо затянуть пояса, либо вообще свернуть свой бизнес.
Вообще нужно смотреть всегда на объем рынка и соотношение спроса и предложения. Если рынок большой и спрос обгоняет предложение — значит для специалиста этот рынок перспективный. Если предложение обгоняет спрос, а объем рынка падает — то лучше с этого рынка уходить.
Ну и не вредно владеть несколькими языками программирования, чтобы иметь больше выбора.
Fedot
26.05.2015 13:27+5Если говорить о вакансиях на полный рабочий день, то зарплаты(в СПб) фактически одинаковые. Поэтому возникает вопрос с чего вы взяли что кто-то выбирает менее оплачиваемую работу?
Удовольствие от работы на php можно получать не меньше чем на любом другом языке. Боюсь что всё неудобство с языком возникает от неумения его использовать.ApeCoder
26.05.2015 13:41Боюсь что всё неудобстово с языком возникает от неумения его использовать.
Насколько по вашему релевантны претензии изложенные здесь?
eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design
Например строковые функции называются каждая на свой манер. Это не создает неудобства?
Вот так не удобней ли?
SerafimArts
26.05.2015 14:17+2> Вот так не удобней ли?
С точки зрения «визуальной красоты» — удобнее. С точки зрения практики — однофигственно. Благо достаточно набрать «lowe», что б получить точно такой же список (из 3х функций) для перевода строковых данных в нижний регистр, вместо использования объектного интерфейса.
На скриншоте Вы приводите пример удобства использования IDE, а не языка. Благо в пыхе две строчки из скриншота сократятся до $number = (int)"42";, что по-моему ещё удобнее и проще.ApeCoder
26.05.2015 14:23+1С точки зрения «визуальной красоты» — удобнее. С точки зрения практики — однофигственно. Благо достаточно набрать «lowe», что б получить точно такой же список (из 3х функций) для перевода строковых данных в нижний регистр, вместо использования объектного интерфейса.
А он поймет, что какие-то функции нельзя применять к строчкам? Если нет единого стиля наименования я не знаю, будет ли слово полностью, или сокращено типа lcfirst.
две строчки из скриншота сократятся до $number = (int)«42»;, что по-моему ещё удобнее и проще.
Конечно, две строчки необязательно:
var number = "42".ToInt();SerafimArts
26.05.2015 14:29Конечно же поймёт: //habrastorage.org/files/158/611/287/1586112872e34c6db967df77ee07933f.jpg
PHP — язык с опциональной типизацией. Если все строготипизированные развиваются из строгой типизации в более слабую (темплейты, обощения и прочее, тот же String STL по сравнению с char* в сях), то в пыхе наоборот — можно использовать строгую там, где она нужна, в остальных случаях игнорировать.ApeCoder
26.05.2015 14:34+1Я так понимаю, что тип переменной $this это не строка.
. Если все строготипизированные развиваются из строгой типизации в более слабую
В чем-то вы правы, но скорее развитие идет в направлении более легкой в использовании типизации, но строгой (вывод типов — вместо манифестной типизации, Generics и т.д.).
SerafimArts
26.05.2015 14:36P.S. Не тот скриншот скинул, но это не важно особо — стандартные функции точно так же подсвечиваются с указанием возможных типов, аргументов и возвращаемых значений, просто изначально у любой скалярной переменной тип mixed (т.е. произвольный) и меняется в рантайме.
$this — это this, ссылка на себя. Я привёл в пример метод, где явно указал тип (в 5ой версии — аннотации, в 7ой — явное указание), но он не обязателен.ApeCoder
26.05.2015 14:44Нет ли проблемы что функции называются очень по разному.
например str_word_count — есть префикс, слова разделены пробелами, нет сокращений кроме префикса ucfirst — нет префикса, глагол сокращен.Fedot
26.05.2015 14:59Такая проблема безусловно есть.
Благо что эта проблема всем известна и её будут устранять в ближайшее время, вполне вероятно что это будет сделано уже в версии 7.1 (https://wiki.php.net/rfc/consistent_function_names)
SerafimArts
26.05.2015 15:00+1Есть конечно, проблема очевидна, но это проблема совсем уж зелёных новичков. Человек, который хоть немного пообщался с этим языком либо будет думать следующим образом «помню была такая функция, как её там, первую букву в верхний регистр, наберу first, о, вот она 'ucfirst'.», либо просто будет знать, либо воспользуется справкой\гуглом — это не страшно.
С другой стороны во многих языках даже нет аналогичных функций перевода самой первой буквы в верхний регистр или подсчёт количества слов в строке, но никто же их не осуждает?
Ещё одним плюсом можно назвать огромное комьюнити, где есть множество своих решений для исправления этой ситуации, причём они довольно просто совместимы друг с другом как раз благодаря слабой типизации, а не как, используя например Java или C# — приходится пройти все круги адовых абстракций, чтоб перегнать вендорный объект одного типа в другой.
Yuuri
27.05.2015 16:34Мне кажется, что вы немного путаете разные системы типизации, другие ваши комментарии это тоже подтверждают. Они могут быть статическими и динамическими, строгими и нестрогими, явными и неявными, мономорфными и полиморфными (причём разными способами), и всё это достаточно ортогональные характеристики. И std::string не «слабее» char * в плане типов, а скорее наоборот.
SerafimArts
27.05.2015 18:08-1Да, верно, постоянно путаю. Но думаю свою мысль я донёс, даже невзирая на то, что откровенно наврал в терминологии. Хоть в PHP и принята динамическая типизация для скаляров — её можно сделать статической (в виде подсветки IDE для PHP 5 или в виде исключений в PHP 7) в аргументах и возвращаемых значениях.
dim_s
27.05.2015 20:10По моему динамическая типизация — это когда переменная может менять свой тип во время выполнения.
Crandel
26.05.2015 14:05а если посмотреть по миру? php там в рейтинге вообще нету
qz.com/298635/these-programming-languages-will-earn-you-the-most-moneysectus
26.05.2015 14:27+1Тут 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 нет. Поэтому эти результаты объявляю подозрительными. Если найдёте исходные данные, то будете молодцом.
Fedot
26.05.2015 14:31Сложно сказать как проводилось исследование, но например вот здесь:
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=
информация совсем иная
И ни та ни другая статистика не показательна. Нужно сравнивать какие-то определённые условия что бы была зоть какая-то картина и объективность, но это не будет отражать действительность в других условиях. Так что на мой взгляд слова о том что на таком-то языке больше зарабатывают, звучит сомнительно.Crandel
26.05.2015 14:49На вашей статистике на python тоже больше зарабатывают. я бы хотел увидеть хоть одну статистику, где пых был бы хоть в тройке лидеров
Fedot
26.05.2015 15:04Без проблем.
ubiznes.ru/skolko-zarabatyvaet/kakaya-zarplata-u-programmistov.html
Здесь питона вообще нет.
Так что очевидно что нужно учить 1C!Crandel
26.05.2015 15:11-2не знаю откуда такая статистика взята, но даже в ней php не вошел в тройку лидеров.
Не хлебом единым.
видимо вы никогда не поддерживали сайт, написанный одним пхпшным файлом. Ради такого «удовольствия» я с радостью пойду работать за меньшую зарплату)))
jonic
26.05.2015 17:19Даже я будучи молодым 14 летним подростком не писал одно-файловый сайт на php -_-
Зато знаю очень крупную компанию внутри которой был бардак и большинство сайтов было просто набором html. И где они? Миллионеры они, так что… спорно все.
dim_s
26.05.2015 16:22www.tiobe.com/index.php/content/paperinfo/tpci/index.html А здесь руби в рейтинге языков на 15 месте, правда по популярности.
ApeCoder
26.05.2015 12:01сверхнизкая стоимость кода
За счет чего?gkopanev
26.05.2015 12:18+2За счет:
1) Простоты
2) Оптимизации для веба
3) Не нужно компилировать код
4) Слабая типизация
5) Много программистов
6) Более низкая зарплата программистов
7) Много бесплатных и платных CMS и Frameworkов
и прочее.
Все это вместе складывается в интегральную величину: «совокупная стоимость владения» которая у любого проекта на PHP в целом ниже, чем у проекта на любом другом языке.ApeCoder
26.05.2015 12:30+2Можете сравнить с Питоном?
В чем простота и оптимизация для веба?
Слабая типизация (не путать со статической и манифестной) это разве преимущество?gkopanev
26.05.2015 12:40Да, это преимущество. Ускоряет разработку. Хотя и делает код менее понятным.
Также преимущество — терпимость языка к ошибкам программирования. Тоже ускоряет разработку и в итоге снижает затраты.
Хотя конечно же с точки зрения true кодера — это выглядит как недостаток.ApeCoder
26.05.2015 13:04+2Мне кажется, это ускорят первичное написание кода, а не разработку в целом (включая исправление последующих ошибок). Хотя, если проект очень маленький и цена ошибки очень невысока…
Или просто дает ощущение скорости разработки.jonic
26.05.2015 17:51Любую ошибку можно отловить и исправить. У меня все FatalException складываются в бд и видны в админке с бэктрейсом, доменом, файлом, строкой, переданными параметрами, и строкой запроса. Бывает там что то? Да. Сколько я это исправляю? минуту и уже хотфикс разворачивается на серверах.
ApeCoder
26.05.2015 17:58Со слабой типизацией трейса не будет, просто по тихому данные загубятся
jonic
26.05.2015 18:02Почему же не будет? Почему загубятся? Я не в состоянии ожидать что то от входных данных? Я не знаю что там будет? Если там должно быть число — оно там и будет и я его строго приведу к числовому типу. Не будет число? Следовательно метод не может работать — кидаем fatal, сохраняем бэктрейс и видим что же погубило нашу функцию. Я не собираюсь спорить у меня это работает прямо сейчас.
ApeCoder
26.05.2015 18:17Я так понял, что если вы забутете что-то к чему-то привести, оно по тизому приведется — не так?
«a» + 1 = «a1», а «1»+1 = 2 — не?jonic
26.05.2015 18:21нет, это работает не так.
«a»+1 = 1
«1»+1 = 2
«a»+«1»=1
для констатации строк используется dot оператор.
следовательно:
«a».1 = Fatal Exception.
«a».«1» = «a1»SerafimArts
26.05.2015 19:50«a». 1 = «a1». без FatalError или FatalException (если мы про PHP).
jonic
27.05.2015 00:35Правда? sandbox.onlinephpfunctions.com/code/e9ff69d28991061b9a3f27348f409a26a2c76c57 Parse Error, но тем не менее. Я на php пишу каждый день и уже очень много лет. Свои слова я аргументирую.
jonic
27.05.2015 00:40хотя, я заметил пробел, но тем не менее сути это не меняет ;)
SerafimArts
27.05.2015 11:38PHP 5.6
//habrastorage.org/files/b99/ebb/a64/b99ebba64b074ef2a5a0a2cdcf3c2a96.png
PHP 5.5
//sandbox.onlinephpfunctions.com/code/6168b24e8ec78e8ed17efb80e0f9591905acba68
Да, а без пробела не работает, т.к. ".2" преобразуется во флоат «0.2», но мы же тут конкатенацию рассматриваем. Но да, каюсь, не заметил отсутствие пробела в самом начале, по привычке (по PSR) поставил его.
VolCh
26.05.2015 12:17+2Хотелось бы мне, чтобы люди могли ответить мне на вопрос «почему бы я сегодня выбрал для себя PHP?».
Не очень понятен вопрос. Выбрал бы для чего? Навскидку варианты:
— сделать стандартный сайт (визитка, бложик или инет-магазин)
— как первый язык программирования
— как основной язык конкретного сложного веб-приложения
— как основной язык профессиональной деятельности
А вообще статья непонятна, что устарелого в PHP? Что в нём есть, что мешает разрабатывать? Каков идеал современного ЯП для разработки сервер-сайда веб-приложений разного уровня от бложика от монстров типа фэйсбука или внутрикорпоративных приложений? Какие отличия от этого идеала делают PHP устаревшим? Рассматривается сам язык, язык со стандартной библиотекой или вся экосистема?
Neuronix
26.05.2015 15:51+1Хммм… Вот честно, для меня проще написать инет-магазин на Java (тот же Play Framework), чем продираться через тысячи стандартных функций PHP. А до джавы — проще было на перле написать. Так что тут всё сугубо индивидуально, но я бы не советовал его к изучению, если бы ко мне обратились с таким вопросом.
Фейсбук, кстати, тоже отказался от PHP в пользу своей версии языка.
xtra
26.05.2015 18:43на PHP можно тоже писать с использованием фреймворков, а фейсбук, насколько я понимаю, отказался в пользу своей версии PHP, а точнее интерпретатора
Casus
26.05.2015 15:49Вот и меня минусуют за моё мнение к PHP. Ладно бы я был фанатом python/ruby, но нет, я пишу на php лет 10 и продолжаю это делать. И со всем своим опытом, я утверждаю, что php — плох, а мне не верят.
Признаюсь, я сам стал понимать глубину проблемы, только после начала изучения Go/Java/Scala.
Не верите мне? Посмотрите статистику использования PHP, популярность падает и поверьте, продолжит падать.SerafimArts
26.05.2015 16:32-3И чем 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. Хотя язык это всего лишь инструмент, и не буду отнекиваться — джава мне тоже нравится.Casus
26.05.2015 17:15+1Оговорюсь, что в большинстве пишу не на 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 можно сразу в гроб класть.SerafimArts
26.05.2015 17:54+11) Есть такое дело, но с другой стороны в пыхе она не нужна и требуется очень редко (с другой стороны в 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 и так далее. Тут можно похоливарить, но в целом я считаю синтаксис пыха более логичным и строгим.Casus
26.05.2015 18:21+11. phthreads — костыль. Идеология пхп умирать не даст вам работать в многопоточности. Потоки и так непростая штука, а бороться еще и с языком… извольте, я просто возьму Акка.
2. стримы есть, а толку? Хоть кто нибудь их использует? Библиотек нет, а react/ratchet построен na libevent — костыль.
П.С. У меня есть статья с исходниками по привязке react на планировщик, построенный на генераторах, и это всё запускает symfony2. Но это всё лабораторные испытания, и совсем не готово для боевых задач.
3. type hinting в пхп ограниченный, даже в 7
4. с введением строгой типизации это становится актуальным, в hack именно так обстоят дела
5. бросьте, даже в 5.5 перегрузка методов былаб очень кстати.
8. есть, мало, но есть, а неблокирующих расширений и того меньше… в результате толку ноль ((
11. согласен, это спорно. Но тут я руководствуюсь краткостью и распространённостью среди других языков.SerafimArts
26.05.2015 19:081. Идеология не мешает ему иметь вменяемый 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». Тоже и касается стрелочки — это только инстанс (объект) и всё, никаких исключений. Двойное двоеточие, тоже без исключений — статический вызов. По долларам можно запросто отличать переменную от константы (любой, хоть структуры или дефайна). Так что может синтаксис и на символ длиннее джавовского, но отсутствие обязательной типизации сокращает код намного больше, а читать его становится проще, просто благодаря изыбточности, но отнюдь не излишней избыточности. Опять же меньшее зло во благо.
webkumo
26.05.2015 19:411. Это, кстати, одна из проблем 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. Только это… свинство, мягко говоря… Напоролся тут недавно — выскочило исключение, которого не ждал… И сломало загрузку модуля.SerafimArts
26.05.2015 20:02> Используйте тип char и сможете складывать чаркоды. Строки в Java всегда содержат как минимум 2 чаркода (см utf-16). Это дело привычки,
В PHP для конкатенации используется точка — это возможность проводить строковые операции отдельно, а математические отдельно. Предлагаю взглянуть на JS, где "+" представляет из себя и то и другое. Много веселья можно обнаружить. Когда код начинает выдавать совершенно невообразимые результаты, просто из-за проблемы динамической типизации.
> Простите, а в php можно статик-метод класса вызывать без использования имения класса?
Да, конечно.
1) Можно от строки вызвать, тогда строка попытается сконвертиться в декларацию класса
2) Можно вызвать из родителя с помощью static
3) Можно вызвать из ребёнка c помощью parent
4) Можно обратиться через рефлексию и ещё тучей всяких способов
> Напоролся тут недавно — выскочило исключение, которого не ждал… И сломало загрузку модуля.
Ну наверное в случае Java throws полезны. Обычно исключениями хочется покидать всякие NotFonudHttpException, PermissionDeniedException, просто по привычке, а чтоб это нормально в java обработать — приходится исправлять километры кода. Но наличие явных мест вылета исключений — несомненный плюс.webkumo
26.05.2015 22:06> В PHP для конкатенации используется точка — это возможность проводить строковые операции отдельно, а математические отдельно. Предлагаю взглянуть на JS, где "+" представляет из себя и то и другое. Много веселья можно обнаружить. Когда код начинает выдавать совершенно невообразимые результаты, просто из-за проблемы динамической типизации.
Тут есть нюанс: в Java статическая типизация и в Java единственное место, где переопределён смысл оператора + — это строки. Поведение однозначное, проблемм не возникает.
>> Простите, а в php можно статик-метод класса вызывать без использования имения класса?
> Да, конечно.
> 1) Можно от строки вызвать, тогда строка попытается сконвертиться в декларацию класса
> 2) Можно вызвать из родителя с помощью static
> 3) Можно вызвать из ребёнка c помощью parent
> 4) Можно обратиться через рефлексию и ещё тучей всяких способов
Не улавливаю чем 1 случай отличается от базового. Насчёт 2го и 3го не скажу — достаточно специфические случаи, а 4ый в равной степени относится к жаве.SerafimArts
26.05.2015 23:50> Не улавливаю чем 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ый в равной степени относится к жаве.
Ну это да =)
З.Ы. Прошу прощения за отсутствие форматирования кода, карма.webkumo
27.05.2015 10:13Ну это уже какие-то чисто php-заморочки, которые мне не понять:
use Some\Any as Test;
2ой и 3ий для меня так и остаются сомнительным юз-кейсом.SerafimArts
27.05.2015 20:12Это не чисто php-заморочки. Это алиасы, которые есть и в Python (import some as any), ActionScript (import Some = any), CoffeeScript ({Some} = Any), C# (using Any = Some) и в прочих.
2 и 3 пункты позволяют более гибко оперировать объектами. По-умолчанию в Java классах при наследовании для статик-методов используется переопределение (поправьте, если я ошибаюсь) и все вызовы без явного указания класса будут обращаться к ребёнку (да ведь?) — в php это аналогично всем `static::*` вызовам. Но в случае когда нужно обратиться конкретно к полю своего класса, а не к будущим потомкам, которые его переопределят — используется `self::*`, что в Java реализуется лишь через `ИмяКласса.метод`.
webkumo
26.05.2015 18:12+сы 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.
kivsiak
26.05.2015 20:17Немного дополню пункт 2 Используя retolambada спокойно можно использовать лямбда выражание из 8. Вообще чем ява хороша почти все что есть в 8 можно бекпортировать через постпроссинг классов.
xonix
27.05.2015 03:24Как там в 2015 — уже привинтили юникод-то?
Один `[]` заменяет HashMap, HashSet, T[] (т.е. массивы) и прочее
И оттого работает чудовищно неэффективно по памяти.
ShadowsMind
27.05.2015 10:38+1Всегда доставляли такие комменты. Вы сравниваете JVM над которой трудятся одни из лучших программистов с PHP, который пилится можно сказать сообществом и энтузиастами. «Есть то, есть се» — это спорные утверждения, то что они есть это еще не значит, что это работает нормально. Взять хотя бы аннотации в комментариях — это вообще нормально!?
Ничего не имею против PHP — потому что не пишу на нем и не собираюсь. Но не нужно делать таких вот утверждений. Когда такое говорят в мире где-то грустит один инженер Oracle…
Adelf
26.05.2015 16:13Меня поражают все эти нападки на язык. Язык лишь инструмент. Функции как-то не по стандарту названы… да я если честно уже не помню когда в последний раз возникали проблемы с этим… IDE(прекрасный PhpStorm от JetBrains) в руки и вперед.
Пишу сейчас на laravel… IoC из коробки. Куча современных паттернов из коробки. Composer — подключаешь что нужно. Пишется легко. Просто уметь надо.
Уже который раз замечаю, что люди, хаящие PHP, просто не умеют его готовить. До сих пор застряли на сайтах из одного PHP файла? include 'database.php'; — где подключаемся к базе данных?
Ну могу лишь предположить что достался большой legacy проект… Видел и такие. Но это проблема проекта, а не языка. Большие legacy проекты есть в каждом языке. Не надо сравнивать старый сайт на PHP и новый сайт на питоне/руби.Casus
26.05.2015 16:32Нападки на язык не ради того чтоб обидеть, язык или разработчиков, а от того, что обидно за php, которому уделял столько времени.
При разработке настаёт момент, когда понимаешь, что решить элегантно проблему на php невозможно, только с помощью костылей или сторонних утилит, а большинство разрабов, такие решения считают нормальными!
Можно возразить, мол вы же знали что php это в прошлом (personal home page), но так случается, что проекты вырастают, иногда больше ожидаемого и тут php подводит.SerafimArts
26.05.2015 16:39С ходу могу назвать только одну вещь, которая в пыхе делается костылями — прокси класс для DI. С удовольствием бы выслушал ещё примерчики, может действительно это случай «не умеешь готовить»?
Casus
26.05.2015 17:23Отложенное выполнение задач.
SerafimArts
26.05.2015 17:381) register_shutdown_function
2) Thread (http://php.net/manual/ru/class.thread.php)
3) Pcntl
4) Cron
А вообще по-хорошему (даже не на PHP) задачи — это некая сущность, которая должна выполняться вне основного треда, включая перезапуск при исключениях и прочее. Так что в данном случае лучше использовать Redis и аналогичные системы, ну или в БД отправлять задачу.Casus
26.05.2015 17:51Ну я же говорил, что можно сделать с помощю сторонних утилит(cron, queue) или костылей (pcntl, phthreads, shutdown_functions).
Поправьте если не прав… но чтоб решить задачу отложенных действий в пхп, нужно добавить асинхронность, а лучше многопоточность, но чтоб это добавить нужно переписать сборщик мусора, переписать расширения чтоб гарантированно (в основных) не текла память, а потом еще раз переписать чтоб вызовы были неблокирующие…
А если это всё сделать, то и мои претензии к пхп сойдут на близкое к нет.SerafimArts
26.05.2015 18:01Ну так и в руби, чтоб половину возможностей получить нужно компилить через devkit с шаманством gcc, никто же не жалуется? В целом — всё верно, встроенных возможностей нет, т.е. нет поддержки у шаред хостингов. Но я имел ввиду проблемы языка (т.е. проблемы при реализации ООП паттернов, например), а не его АПИ.
Так что имхо, такие возможности есть, возможности не костыльные (thread — это потоки, pcntl — это процессы), а то, что это dll\so — это уже другой вопрос. Костылём можно посчитать, например запущенный процесс пыха, как менеджера очередей, и общение с ним через сокеты или шаред мемори.Casus
26.05.2015 18:39А я и не говорю за руби или питон… У меня там слишком мало опыта.
Потоки для пхп — костыль. Потому что неродное, потому что работать будет только в каких-то исключительных ситуациях, но не как mainstream. Не костыль для пхп это асинхронность средствами генераторов, хотя и это выглядит побочным эффектом.SerafimArts
26.05.2015 19:16Ну так задачи, из реальной жизни, где прямо срочно нужны потоки — практически мифические. Вы привели в пример очереди, для них существуют специальные сервера очередей (RabbitMQ), существуют общие решения (Redis, Taratool, SQL-Like DB, etc...) и даже в языках, где есть нативная поддержка тредов — вряд ли будут их использовать для этого, разве что как временное решение.
tzlom
26.05.2015 18:13Отложенное выполнение задач не должно выполняться веб сервером, для этого есть крон или сервисы очереди задач.
Выполнять отложенные задачи создавая ещё один поток (или пользуясь пулом потоков) на веб-сервере, это как писать весь РНР код в одном файле.
Если вы имеете ввиду продолжение работы после формирования ответа на запрос — это в РНР есть и даже двумя способами -пул функций исполняемых перед завершением процесса и принудительное формирование ответа с закрытием сокета, первое удобно использовать в подключаемых библиотеках т.к. можно не напрягать пользователя библиотеки ручным завершением работы, второе удобно использовать в приложении.Casus
26.05.2015 18:331. пхп — не сервер
2. пользоваться пулом потоков для отложенных задач — моветон? с каких пор?
3. «перед завершением процесса» — вы серьёзно не видите проблем в таком решении?
Простите, но Вы очень похожи в своих суждениях на человека который ползуется костылями и реально считает, что это так и должно быть.tzlom
26.05.2015 19:24А вы очень похожи на человека который никогда на РНР не писал, но не одобряет
1 — РНР-fpm если не сервер то что тогда?
2 — да, отложенные задачи гонять на сервере приложений это моветон, смотрите сами:
* раз задачу можно отложить, значит для ответа на запрос она не нужна, тогда почему её обслуживает веб-сервер
* часто откладывают ресурсоёмкие задачи, однако у ресурсоёмких задач могут быть другие требования к програмному окружению и настройкам среды — зачем веб серверу в зависимостях ffmpeg?
* откладывают задачи потому что медленные, при росте сервиса это первый кандидат на дешёвое горизонтальное масштабирование, если у вас это в веб-сервер не встроено конечно
3 — Посмотрите как РНР работает, он «умирает» после каждого соединения, можно конечно сказать что это неоптимально, но многие задачи так решаются гораздо эффективнее, например можно значительно реже вызывать GC и не бояться что память исчезнет, ну и Erlang стоит упомянуть где эта штука возведена в абсолютCasus
27.05.2015 11:421. а с чего вдруг 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
tzlom
26.05.2015 18:14Зачем вам прокси класс? Есть как минимум две DI для РНР не использующие прокси классов.
SerafimArts
26.05.2015 18:20Ну не только для DI. В идеале для реализации декораторов и в целом обсерверов на поля и методы. Просто DI является контейнером с резолвом зависимостей, так что они (обсерверы) туда идеально легли бы.
Adelf
26.05.2015 16:54Да я и не обижаюсь. Иногда мне не хватает статики в PHP… это единственное что меня в языке смущает. но PHP7 движется в правильном направлении.
kelevra
26.05.2015 21:40-6странно, что ещё никто не запостил.
skobkin
26.05.2015 23:20+1Всегда радовали набросы про работающих за еду.
Интересно, почему на том же бывшем oDesk есть толпы программистов за $3-5 в час, а есть программисты за $15-30 и более?
Наверное, те, кто работают за $3-5 просто не знают, что можно попросить больше.
ruslanys
26.05.2015 23:30Бла-бла-бла. Очередной холивор. А кто-нибудь ответит на вопрос как решаются задачи параллелизма на PHP?
kivsiak
26.05.2015 23:33Ну это удар ниже пояса. Хотя я раз за разом вижу как они гордятся своим костылями. И оно таки да! Заслуживает гордости ибо умудряется работать.
ruslanys
26.05.2015 23:50Ирония в том, что правильного ответа на этот вопрос нет. PHP — язык, для решения другого рода задач. Нет ничего лучше PHP, для решения задач разработки персональных страниц, форумов, простеньких интернет-магазинов, все эти задачи избыточно решать на том же С, или Java. Но и PHP ставить в ряд с Ruby, Python и уж тем более с C, Java, .NET (C#) — просто глупо.
xonix
27.05.2015 03:34-1Наблюдаю краем глаза за лавинообразным развитием пхп последних лет, и сделал парадоксальный вывод. Чем быстрее пхп развивается, тем быстрее он умрет. Очень просто. Из него сделают недо-яву (без юникода, потоков, толковой типизации, тормозную, с «шумным» синтаксисом), и люди получат больше оснований сравнивать.
А сравнив, сделают очевидный вывод.
Процесс запущен.
Мой прогноз: пхп умрет, когда отменят доллар в имени переменных.Fedot
27.05.2015 11:20+1> Мой прогноз: пхп умрет, когда отменят доллар в имени переменных
Т.е. никогда, так как синтаксис языка не позволит это сделать, да и не нужно это никому.xonix
27.05.2015 15:37Почему не позволит? Вот заменили array() -> [] тоже все удивлялись.
Что такого принципиально невозможного? Почему в куче языков возможно, а в пхп нет?SerafimArts
27.05.2015 16:00Потому что доллар, хоть и не совсем красиво, но это удобно:
1) Сразу видно где переменная, а где константное значение (константа, дефайн, структура)
2) Позволяет объявлять одинаковые имена для полей, методов и констант
3) Позволяет экспортировать переменную из строковых значений ($$var)
4) Позволяет не конфликтовать с именами функций и классов (т.е. иметь строгость в отношении их переопределения, как минимум)
5) Позволяет отделять ключевые слова от имён переменных (например создать переменную с именем $class)
6) Позволяет интерполировать переменные без лишних спец.символов (это уже Bad Manners, но всё же фича языка)
Убирая доллары из языка потери по функциональности будут в разы больше, чем просто привычка видеть переменные без долларов.xonix
27.05.2015 16:53-2Бывает удобно — иногда, а некрасиво — всегда.
Понятно, что можно найти тысячу оправданий несовершенству парсера. Туда же ::, \, -> и прочие.Fedot
27.05.2015 17:18Что вас смущает в красоте?
По мне так код выглядит лучше чем во многих других языках
Когда мне приходиться писать на Java, мне не нравится как выглядит код
Но это дело вкуса и привычки
SerafimArts
27.05.2015 18:56Двойное двоеточие позволяет визуально определить где обращение к объекту, а где вызов статики:
$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`.xonix
27.05.2015 19:17Двойное двоеточие позволяет визуально определить где обращение к объекту, а где вызов статики:
А здесь обращение к объекту или к статике?
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.
Ну и зачем оно нужно было чтоб потом юзвери путались что им писать?
Чтоб обосновать выбор стрелочки в качестве доступа к объектам — надо пойти чуть глубже: Распространённая практика использования символа "+" для конкатенации строковых значений.
Это все понятно. Череда обратных совместимостей породила монстра. Нет, обратная совместимость, безусловно, нужна. Даже важнее чем новые фичи. Но Вы же сами оголяете противоречие. С одной стороны Вы говорите, что синтаксис был обусловлен уже существующими конструкциями языка, и с другой пишете что вам полученный синтаксис нравится даже больше. Совпадение? Возможно. Но больше похоже на оправдание.SerafimArts
27.05.2015 19:58> А здесь обращение к объекту или к статике?
Возможно два варианта:
1) parent — это не переменная (там нет доллара), а обращение к родителю из текущего контекста (в данном случае из метода инстанса), а следовательно не должно быть и исключений из правил.
2) Начиная с какой-то там версии к статическим методам больше нельзя (на словах) обращаться через "->" и наоборот. PHP до сих пор позволяет это делать, но выкидывает то ли варнинг, то ли ошибку, мол «очень плохо». Вполне возможно, что эта конструкция осталась со времён, когда это было нормальным. Именно об этом и гласит строчка про варнинг (скорее всего), что в некоторых конфигах и версиях PHP ошибки могут подавляться и вызов возможен.
Итог: Возможно хорошим решением было бы добавление переменной "$parent->". Но вполне возможно это просто избыточно. Но замечание отличное, я об этом не подумал как-то даже.
> Это все понятно. Череда обратных совместимостей породила монстра.
Объекты со стрелочками были в C++ начиная с древнейших времён, никому оно не мешало, ну и php-сообществу тоже не особо (мне в том числе). Привычно, удобно, всё видно. И нет, не совпадение, а дальновидность дизайнеров языка, которой я поражаюсь. Но естественно всего предусмотреть нельзя. Думаю стоит посмотреть вот этот доклад, довольно интересный: www.youtube.com/watch?v=CX_K1r0Vklg (хоть он и о Java, но даёт представление о том, с чем сталкиваются проектировщики)xonix
27.05.2015 20:36+1И нет, не совпадение, а дальновидность дизайнеров языка, которой я поражаюсь.
Блин ну в чем дальновидность-то?
Может быть в этом? (за достоверностью цитаты к автору поста)>>
Вместо этого Рамус Лердорф говорит вещи навроде:
У нас есть защищённые свойства, абстрактные методы, вся эта фигня, про которую ваш учитель информатики вам рассказывал. Мне на всё это дерьмо плевать.
Или в этом:
Хозяйке на заметку: PHP в линейном массиве из int-ов отводит где-то по 70-80 байт на элемент.
david-m.livejournal.com/1117497.htmlSerafimArts
27.05.2015 20:46Расмус — _один_из_ разработчиков, а не разработчик. Он придумал, но не он проектирует. Вот список современных контрибютеров: 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 всё равно быстрее всех существующих аналогов (яп с динамической типизацией).
К чему всё это?xonix
27.05.2015 20:56SerafimArts
28.05.2015 05:14Ясно, спасибо. Только как всё это дело относится к дизайну языка?
xonix
28.05.2015 15:48-1Очевидно, как. Додуматься впихнуть список и словарь в одну структуру — «гениальное» дизайнерское решение.
SerafimArts
28.05.2015 17:13Это скорее архитектурное, а не дизайнерское решение. Вы путаете понятия. Я ещё раз кину ссылку на видеоролик в ютубе: www.youtube.com/watch?v=CX_K1r0Vklg на который я уже ссылался несколькими комментариями выше. Стоит всё же найти время и посмотреть его.
Если совсем кратко, то дизайн языка — это «как получать», а не «что получать». Небольшая капелька декларативности так сказать.
Prapor
27.05.2015 11:13+2На моей памяти умерло два отличных инструмента своего времени Clipper и Delphi и единственной причиной этому стало прекращение развитие самого инструмента. Думаю то же самое можно утверждать и о Perl.
К примеру, Clipper так и не смог вовремя перепрыгнуть на SQL БД, не смог предложить RAD систему создания приложений. В результате, другие инструменты просто заменили его.Та же история произошла и в Delphi
Проблем с застоем в PHP пока не наблюдается, сообщество и разработчики постоянно шевелятся и обновляют как сам инструмент так и вспомогательную инфраструктуру регулярно.
Все остальное от лукавого.
SerJook
27.05.2015 15:02-5PHP — это дно, не идите люди в PHP, потом не выберетесь из этого дерьма.
Я работал с пхп-шниками, и честно говоря, они мне вы##ли мозг своей тупостью. Большинство из них не имеют ни малейшего представления о разработке ПО.
Это не удивительно, ведь многие из них начинали с создания сайтиков на джумле/вордпрессе/самописном г-движке.
Собственно, то что они сейчас делают, трудно назвать ПО. Гонятся за модными фреймворками, не имея при этом фундаментальных знаний в области разработки. В общем, в этой среде трудно стать настоящим профессионалом.
IvanIDSolutions
13.06.2015 10:39+1Не услышал ни одного нормального довода, да и главное, что же лучше, если автор говорит что пхп устарел, то, что же тогда новое и мощное и хорошее должно придти на замену?
artyfarty
или «Мне понравился язык Z, и теперь мне кажется открылась сама Истина, поэтому я нагуглил аргументов против языка X ну и Y заодно»