Comments 82
Golang хотя-бы звучит.
Лично я, выбирая между PHP и чем-то другим, выбрал бы что-то другое, просто потому, что PHP нигде не работает одинаково (только если у вас не дефолтный php.ini, но такого практически не бывает) — и именно этот факт является самым большим источником ошибок и прочих проблем.
Но PHP все же лучше других скриптовых языков подходит для разработки больших долго-живущих проектов, благодаря своей выразительности и достаточно простой структуре кода (хотя, Python для этого подходит гораздо больше).
Но PHP все же лучше других скриптовых языков подходит для разработки больших долго-живущих проектов, благодаря своей выразительности и достаточно простой структуре кода (хотя, Python для этого подходит гораздо больше).
PHP нигде не работает одинаково
Не могли бы вы раскрыть этот момент подробнее?
Поведение очень многих стандартных функций зависит от глобальных настроек в php.ini. И даже используемый синтаксис зависит от них. Нет возможности поменять эти настройки для своего кода, не ломая весь остальной код в проекте.
В целом, это не является проблемой на самом деле. Это больше надувание слона из мухи. Уже давно в пхп используется менеджер пакетов, который совмещает в одном проекте сотни библиотек, и всё ведь работает. Да и вообще, сколько лет я уже использую пыху — честно, еще ни разу не возникло подобной проблемы. Такое ощущение, что вы просто взяли подобные доводы из какой-то старой статьи про недостатки пхп, сами при этом не особо зная о реальном положении дел.
В общем, всё нормально на самом деле в этом плане в пхп. Это вообще не проблема, то что описывается проблемой — высосано из пальца и раздуто до слона.
В дополнения к комментарию выше хочу сказать что многие настройки давно можно менять в самом php файле для 1 файла во время исполнения скрипта (ini_set), что мешает это сделать в проекте, если в этом есть крайняя необходимость?
Насколько я знаю, ini_set не меняет их для одного файла, а меняет глобально.
Выдержка из документации:
«Устанавливает значение заданной настройки конфигурации. Настройка будет хранить установленное значение пока выполняется скрипт. После завершения работы скрипта значение настройки вернется к исходному.»
http://php.net/manual/ru/function.ini-set.php
«Устанавливает значение заданной настройки конфигурации. Настройка будет хранить установленное значение пока выполняется скрипт. После завершения работы скрипта значение настройки вернется к исходному.»
http://php.net/manual/ru/function.ini-set.php
Было бы интересно услышать возражения. izac даже привёл пример из документации, подтверждающий мои слова:
Настройка будет хранить установленное значение пока выполняется скрипт.
Или большинство не знает, что значит слово «глобально»?
Зависит, но этот хлам начали вычищать и сводить несколько идентичных по сути настроек к одной.
Вы не управляете своим собственным php.ini?
Такое бывает только на shared-хостинге, что при цене современных VPS/VDS — просто смешное ограничение (а очень хороший качественный shared даже дороже VPS/VDS — просто потому что там одна и та же базовая технология, но для shared админы хостера трудятся чуть больше).
Для более сложных систем есть Docker с его изоляцией и возможностью иметь свой индивидуальный файл php.ini для каждого куска вашей системы.
Такое бывает только на shared-хостинге, что при цене современных VPS/VDS — просто смешное ограничение (а очень хороший качественный shared даже дороже VPS/VDS — просто потому что там одна и та же базовая технология, но для shared админы хостера трудятся чуть больше).
Для более сложных систем есть Docker с его изоляцией и возможностью иметь свой индивидуальный файл php.ini для каждого куска вашей системы.
UFO just landed and posted this here
Ну, не в защиту предыдущего оратора будет сказано, но, тем не менее, возможность редактировать php.ini на некоторых shared-хостингах все-таки имеется. Например, у Ру-Центра.
А, то есть Slack выбрали PHP по вашему мнению именно из-за возможности установить на shared-хостинге? Пользую пыху > 5 лет, ни разу не пользовался shared-хостингом. Я пыхарь, как вы выражаетесь и моим аргументом НИКОГДА небыло «возможность запуска на shared». VPS\VDS — не аргумент в пользу пыха. Не аргумент в пользу чего бы то ни было вообще. А php.ini несложно расценивать, как environment variables которые есть почти в любом веб-проекте на любой технологии.
Вы не управляете своим собственным php.ini?
Очень странный вопрос. Нет, когда я пишу бибилотеку, я не управляю php.ini окружения, где будет выполняться код. Я не знаю, какое будет значение у arg_separator.output, short_open_tag, allow_url_fopen и еще тысячи настроек, которые влияют на выполнение кода.
Но конечно, если весь код проекта пишет строго один человек под одно окружение, это не проблема. Но статья вроде о PHP всерьёз.
Вы либо описываете этот нюанс в документации к своему ПО в разделе «Требования».
Либо пишете так, чтобы работа вашего кода не зависела от этих настроек.
Во всем мире с этим как-то борятся, а в PHP — это принципиально невозможно, что ли?
Или вы думаете, что в мире вне PHP не существует настроек системы, не зависящих от разработчика ПО?
Либо пишете так, чтобы работа вашего кода не зависела от этих настроек.
Во всем мире с этим как-то борятся, а в PHP — это принципиально невозможно, что ли?
Или вы думаете, что в мире вне PHP не существует настроек системы, не зависящих от разработчика ПО?
Вы либо описываете этот нюанс в документации к своему ПО
Ну вот автор одной бибилотеки написал одни значения, а автор другой — другие. А свой код я писал в расчете на третьи. И что делать?
Во всем мире с этим как-то борятся
Во всем мире, если есть какие-то настройки, они существуют на уровне модуля. Их можно поменять под себя, не ломая весь остальной код, запускаемый в этом же компиляторе или интерпретаторе.
Вы мало знаете о мире.
Или просто настроены пессимистично — у всех все хорошо, а у одного меня все плохо.
Это не так.
Или просто настроены пессимистично — у всех все хорошо, а у одного меня все плохо.
Это не так.
В соседнем посте рассказывают, что C тоже может зависеть от окружения. Что делать-то теперь, как с этим жить?
Вы на практике встречали хоть раз нестандартное значение
И мне вот сходу сложно представить, каким образом кусок лапши, зависящий от
Вы на практике встречали хоть раз нестандартное значение
arg_separator.output?И мне вот сходу сложно представить, каким образом кусок лапши, зависящий от
short_open_tag получил звание «библиотеки». Мы ведь сейчас не в 1998 году находимся, и даже не в 2006.
Ну вот автор одной бибилотеки написал одни значения, а автор другой — другие. А свой код я писал в расчете на третьи. И что делать?Дело в том, что «разные настройки» это скорее не разные возможности, а экивоки в пользу кода со странностями.
Для яркого примера можно взять те же регистр-глобалс, которые можно было в настройках включать, а можно было выключать.
Если код написан правильно и современен — разные настройки проблему не создают. Если же код написан неправильно или несовременен — это проблема кода. Используйте современные либы, пишите современный код не используя спорных решений и все будет ок:)
Это общая проблема веб-разработки, никак не относящаяся к PHP. И даже к веб-разработке. x64 x86 — слышали?
Хотеть менять arg_separator.output — это в наше время, как минимум, странное желание. Если какой-то уником на своем хосте играет с этим параметром — он сам себе злобный Буратино.
На short_open_tag уже много лет никто внимания не обращает, стандартом де-факто давно стало использование полной формы записи, а для вывода начиная с версии 5.4 всегда доступно <?=.
allow_url_fopen — это, вообще-то, директива безопасности, и это вполне нормально, когда параметры безопасности задает владелец хоста, а не писатель библиотеки.
В общем, сдается мне, насчет «тысячи настроек, которые влияют на выполнение кода» вы слегка перегнули, и при внимательном рассмотрении этих настроек, которые стоит учитывать в коде, останется вряд ли больше десятка, да и те, как правило, связаны с безопасностью, что вполне разумно.
На short_open_tag уже много лет никто внимания не обращает, стандартом де-факто давно стало использование полной формы записи, а для вывода начиная с версии 5.4 всегда доступно <?=.
allow_url_fopen — это, вообще-то, директива безопасности, и это вполне нормально, когда параметры безопасности задает владелец хоста, а не писатель библиотеки.
В общем, сдается мне, насчет «тысячи настроек, которые влияют на выполнение кода» вы слегка перегнули, и при внимательном рассмотрении этих настроек, которые стоит учитывать в коде, останется вряд ли больше десятка, да и те, как правило, связаны с безопасностью, что вполне разумно.
Ссылки на библиотеки, пожалуйста.
Юзайте Vagrant и будет у вас один енвайронмент и будет РНР работать всюду одинаково
Как только мы уходим от shared hosting, необходимость в PHP отпадает в принципе.
Сразу появляется простор для RoR, Django, Go etc.
До первой необходимости начать расширяться — да, всё очень даже не плохо. А потом начинается как в том комиксе про белок-истеричек:
«А-а-а-а-а-а! У нас пол проекта зависит от сохранения состояния!»
«А-а-а-а-а-а! У нас слишком много данных бегает между приложением и memcache/redis/whatever для сохранения стейта, у нас гигабитный линк ложится!»
И так далее.
Слишком многие расслабляются и имеют потом огромные проблемы с разработкой и поддержкой. Кто-то справляется, кто-то нет. Тех, кто знают на что идут и планируют правильно на самом деле довольно мало — в основном те, кто уже опытные и скорее всего они провели значительное время в выбранной технологии, а не 2-3 года. Настоящие профи в любом языке и технологии это те, кто активно и серьёзно работали хотя-бы 5-7 лет.
Да и со временем значительное кол-во человек всё равно возвращаются к PHP, потому что работы на RoR, Python и Go не настолько много — на всех не хватает.
У меня есть щас клиент, которому девелоперы сделали магазин на Django & QShop — сейчас всё переносим на платформу на Symfony, потому что за относительно простые вещи начали выкатывать такие ценники, что ппц — клиентам оказалось дешевле заплатить нам за полный перенос магазина на новую платформу и заниматься её развитием, чем пытаться заниматься модификацией Django Qshop для добавления весьма тривиальных вещей.
«А-а-а-а-а-а! У нас пол проекта зависит от сохранения состояния!»
«А-а-а-а-а-а! У нас слишком много данных бегает между приложением и memcache/redis/whatever для сохранения стейта, у нас гигабитный линк ложится!»
И так далее.
Слишком многие расслабляются и имеют потом огромные проблемы с разработкой и поддержкой. Кто-то справляется, кто-то нет. Тех, кто знают на что идут и планируют правильно на самом деле довольно мало — в основном те, кто уже опытные и скорее всего они провели значительное время в выбранной технологии, а не 2-3 года. Настоящие профи в любом языке и технологии это те, кто активно и серьёзно работали хотя-бы 5-7 лет.
Да и со временем значительное кол-во человек всё равно возвращаются к PHP, потому что работы на RoR, Python и Go не настолько много — на всех не хватает.
У меня есть щас клиент, которому девелоперы сделали магазин на Django & QShop — сейчас всё переносим на платформу на Symfony, потому что за относительно простые вещи начали выкатывать такие ценники, что ппц — клиентам оказалось дешевле заплатить нам за полный перенос магазина на новую платформу и заниматься её развитием, чем пытаться заниматься модификацией Django Qshop для добавления весьма тривиальных вещей.
Ну с учетом того, что PHP7(Symfony 2\Laravel\Zend2 и т.д) производительнее вашего RoR и Django, а цена среднего PHP-девелопера ниже специалиста того же уровня на RoR, Django, я уж не говорю о Go, то выбор НЕ в пользу PHP в данной ситуации кажется как раз намного более странным.
«Я утверждаю, что разработка на PHP в стиле «подумать, отредактировать и перезагрузить страницу» делает разработчиков более продуктивными. В долгих и сложных циклах разработки проектов это даёт ещё больший прирост.»
Вот тут вы очень сильно ошибаетесь, ибо перезагрузить страницу, где куча состояния и взаимодействия, чтобы добраться до какой-то минифичи — это неземная боль.
Вот тут вы очень сильно ошибаетесь, ибо перезагрузить страницу, где куча состояния и взаимодействия, чтобы добраться до какой-то минифичи — это неземная боль.
Это же перевод…
Ну автор оригинальной статьи, заблуждается (или нарочно вводит в заблуждение).
Я что-то неправильно перевел?) Предложи свою версию перевода этого предложения, Грибок: I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. Over the course of a long and complex software project’s life cycle, these productivity gains compound.
А что это меняет? Типа: чувак же на английском написал, он не может ошибаться?
Это не так, на самом деле во многих других языках очень популярны инструменты имитирующие такую логику, тот же JRebel и Java, а в Spring Framework (Java) вообще практически из коробки идут инструменты позволяющие на лету при изменении исходников либо рестартить сервер, либо релоадить загруженные классы.
P.S. А если взять популярную нынче тему с микросервисами, то микросервис обычно простое веб-приложение, которое не хранит кучу состояний, да и вообще, состояние это противоестественно для REST!
P.S. А если взять популярную нынче тему с микросервисами, то микросервис обычно простое веб-приложение, которое не хранит кучу состояний, да и вообще, состояние это противоестественно для REST!
не используйте MVC паттерн и никакой боли не будет. Я например использую свой собственный (а что было делать) компонентный фреймворк, где состояние страницы сохраняется между вызовами (ну типа как в ASP WebForms только механизм другой) и никакой нечеловеческой боли не испытываю.
но 0123 == '0123foo' является ложью (хмм).
0 указывает на восьмиричную систему счисления. Так что здесь как раз все ок.
Спасибо за хороший перевод интересной статьи.
по сабжу, да, парни сделали с php казалось бы невозможное, они такие модники)
или же у них не было иного выбора для накопившегося легаси;)
по сабжу, да, парни сделали с php казалось бы невозможное, они такие модники)
или же у них не было иного выбора для накопившегося легаси;)
PHP отличный язык программирования, который идеально подходит для большинства сайтов.
Те кто утверждает обратное, просто застряли в 2000м или в своих причудах «нормальных языков».
Те кто утверждает обратное, просто застряли в 2000м или в своих причудах «нормальных языков».
php — замечательный язык, который позволяет быстро и малыми силами добиваться поставленных целей в одной достаточно четко очерченной области. Со своими минусами — куда без них. Но минусы в большинстве своем простые, явные и их довольно легко обойти, не впадая в борьбу с языком (как это бывает во многих популярных языках, ага). Так что совершенно непонятны нападки на него со всех сторон в течение последних лет. Складывается впечатление, что вместо того, чтобы выбрать правильный инструмент и делать дело, людям интереснее изливать свои печали в бложиках :(
Мне кажется, что большенство недовольных как раз новички. Они хотят учить новые технологии, ведь кому понравиться догонять. Конкурировать со старыми разработчиками с 10 лет опыта на PHP не получиться, а вот выучив NodeJs можно сразу получать норм зарплату при опыте 1-2 года и считатся спецом. Поэтому и испытывают негатив к пхп, не совсем понимая причин. Как доказательство, скажем постоянно слышу что Python более объектно ориентрованый, но на самом деле поддержка ООП в PHP Существенно шире. Просто новички видимо думают что ООП, это когда вызываешь метод через точку. А в PHP действительно скаляры не объекты и множество функций со старых времен.
Бредятина.
Уровень вашей зарплаты зависит не от инструмента, а от квалификации.
И от понимания куда с вашей квалификацией вы можете податься.
С PHP ситуация следующая:
Есть много работы, но и есть много дешевой рабочей силы.
Это позволяет легко начать работать.
С Node ситуация такая:
Работы намного меньше, её еще надо поискать, но и рабочей силы меньше.
Поэтом средняя планка зарплаты — выше. Но найти работу сложнее.
Если вы стали профи PHP, то не совершайте ошибку — не конкурируйте с индусами за плошку риса. Не толкайтесь с ними локтями на дешевом рынке.
Идите в сложные системы — и заработок вас приятно поразит.
Уровень вашей зарплаты зависит не от инструмента, а от квалификации.
И от понимания куда с вашей квалификацией вы можете податься.
С PHP ситуация следующая:
Есть много работы, но и есть много дешевой рабочей силы.
Это позволяет легко начать работать.
С Node ситуация такая:
Работы намного меньше, её еще надо поискать, но и рабочей силы меньше.
Поэтом средняя планка зарплаты — выше. Но найти работу сложнее.
Если вы стали профи PHP, то не совершайте ошибку — не конкурируйте с индусами за плошку риса. Не толкайтесь с ними локтями на дешевом рынке.
Идите в сложные системы — и заработок вас приятно поразит.
Могу поддержать — нужно не сидеть на WordPress и прочих, а вливаться в настоящее программирование, большие проекты и.т.д. — там сейчас PHP себя прекрасно чувствует и серьёзной высоко оплачиваемой работы вполне хватает.
Но и знать нужно гораздо больше, чем хватает для работы с WP даже в запущенных случаях.
Для примера: мне пришлось вычищать 5.0 проект от всех ошибок, варнингов, фаталов и несовместимостей перенося всё на 5.6. Для этого нужно иметь опыт, мозги и знать что менялось от версии к версии, как, почему, и понимать как переписать то, что не поддаётся простому исправлению.
Но и знать нужно гораздо больше, чем хватает для работы с WP даже в запущенных случаях.
Для примера: мне пришлось вычищать 5.0 проект от всех ошибок, варнингов, фаталов и несовместимостей перенося всё на 5.6. Для этого нужно иметь опыт, мозги и знать что менялось от версии к версии, как, почему, и понимать как переписать то, что не поддаётся простому исправлению.
людям интереснее изливать свои печали в бложиках
… написанных на PHP, кстати
Приятно что еще остались люди неподдавшиеся яваскриптовому безумию.
А я прочел и подумал, как хорошо, что это пэхэпэшное безумие позади.
Тссс!!! Тихо-Тихо!!!
В PHP 10 лет, годами наблюдал следующий процесс появления нового «php-программиста»:
1) студент, окончил абстрактный не технический вуз — в поисках работы.
2) 0 опыта работы, но в институте преподавали html — устроился работать контенщиком
3) пол года опыта работы: смог вставить countdown скрипт на сайт, заменил логотип в страничке. Все, через месяц уволился и устроился работать верстальщиком
4) прошел год — смог установить по инструкции плагин на <популярная cms на php>, требующий двух правок в php-файлах — все — бежит работать php-программистом.
И вот 2 года назад случилось чудо, очередной такой студент на моих глазах стал не php-программистом, а… внезапно открыл в себе талант backend-разрабочика другой технологии…
P.s. Быть может скоро и 1С-Битрикс перепишут… это же идеально, разрабатывать frontend и backend на одной технологии… можно нанимать меньше разработчиков, ведь явно любому frontend разработчику можно дать задачу backend'щика и наоборот. Эй эффективные менеджеры, где вы?
В PHP 10 лет, годами наблюдал следующий процесс появления нового «php-программиста»:
1) студент, окончил абстрактный не технический вуз — в поисках работы.
2) 0 опыта работы, но в институте преподавали html — устроился работать контенщиком
3) пол года опыта работы: смог вставить countdown скрипт на сайт, заменил логотип в страничке. Все, через месяц уволился и устроился работать верстальщиком
4) прошел год — смог установить по инструкции плагин на <популярная cms на php>, требующий двух правок в php-файлах — все — бежит работать php-программистом.
И вот 2 года назад случилось чудо, очередной такой студент на моих глазах стал не php-программистом, а… внезапно открыл в себе талант backend-разрабочика другой технологии…
P.s. Быть может скоро и 1С-Битрикс перепишут… это же идеально, разрабатывать frontend и backend на одной технологии… можно нанимать меньше разработчиков, ведь явно любому frontend разработчику можно дать задачу backend'щика и наоборот. Эй эффективные менеджеры, где вы?
На какой «одной технологии»? Фронтенд давно уже не мыслим без JS
Или вы нам из прошлого века пишете?
Или вы нам из прошлого века пишете?
Говорить "одна технология" в адресс node.js нельзя. Все почему-то забывают, что до ноды уже существовал серверный JS, но он не был так популярен. Вся хитрость в libuv, который позволяет творить настоящую магию, и JS тут лишь синтаксический сахар.
UFO just landed and posted this here
Очень рекомендую это сделать. Возможно в вашем проекте очень много оверхеда идет на иммутабельные объекты(чтение конфигов, ядро фреймворка и т.д.) или если просто пугает асинхронщина — начните с php-pm.
Мы получили огромный прирост производительности сохранив stateless модель для обработки запросов.
Мы получили огромный прирост производительности сохранив stateless модель для обработки запросов.
UFO just landed and posted this here
На тему ускорения есть ещё такая штучка как Kraken PHP Framework:
Kraken is able to emit millions of events and thousands of messages and connections per second using single container. It is scalable for multiple processes and threads, faster than traditional PHP approach and able to handle same or higher amount of connections that Node.js.
Да собственно вот они все: asynchronous-php
В amphp больше всего верю, потому что там ребята из php-internals и самое главное — с ними отлично получается лично контактировать хоть на гитхабе, хоть в твиттере.
В amphp больше всего верю, потому что там ребята из php-internals и самое главное — с ними отлично получается лично контактировать хоть на гитхабе, хоть в твиттере.
Бесконечные споры же. Ну вот знаю я языков 7, наверно. Многие присутствующие наверно и больше ещё. Ну нет большой разницы на чём писать (кроме сильно несовместимых с языком вещей, но и то люди умудряются делать). Где-то большое прямо в языке есть, где-то библиотеку какую подключить. Где-то сахарку побольше, где-то поменьше. А тут прям выбор тысячелетия… Пустое это всё.
Добродетели PHP
Первая, состояние.
Мне кажется это не отличительная особенность ПХП. В других языках есть способы получения такого же эффекта (константы, и т.п)
И то что ПХП стартует новый процесс на каждый запрос — называть «чистым состоянием» (или как там?) не очень верно.
я уже гдето писал откуда берется негатив. Так как работающих проектов на PHP очень много, то прийдя на работу и не зная PHP часто приходится его изучать. Обратная ситуация встречается реже.
Большинство программистов, которые немного игрались с PHP, знают две вещи про него: это плохой язык, который они никогда не станут использовать при наличии выбора
В любом языке можно найти что-то кажущееся странным, например как тут
сам php вполне себе норм, но вот часть тех, кто на нем пишут — это ппц Х_х. Вроде бы на дворе 2016 год, а на работе в проектах от другой команды до сих пор видны ошибки вида «cannot modify header information — headers already sent» или же ошибки выполнения sql-запросов (вообще только за то, что это видит пользователь на странице, нужно отрывать руки с корнями)
Потому мне кажется, что всех кто связан с php можно разделить на 2 лагеря:
староверы — это те, кто работает с 1-2 cms, могут написать под них модуль, при работе с другими системами не могут переключиться на другой подход потому что привыкли, в основном делают сайты-визитки и шаблонные простые интернет-магазины клиентам. Про автоматизированное тестирование не слышали или же считают что проверить вручную будет быстрее. Таких лучше не подпускать к даже немного сложным проектам. Пишут в стиле php4 до сих пор, развитием языка и новыми фишками не интересуются. Код пишется в каком-нибудь notepad++. Деплой — закинуть файлы через фтп и залить дампы новых таблиц через phpmyadmin.
приверженцы современного подхода — эти люди чтят psr, работают с современными фреймворками, знают как работает веб-сервер и могут спокойно сами его настроить оптимально в зависимости от проекта. Вполне себе пишут еще на нескольких языках или хотя бы имеют представление о других подходах. Пишут тесты и знают какие они бывают. Стараются использовать последние фишки языка. Для работы используют IDE (phpstorm, netbeans и т.п.). Деплой чаще всего автоматизирован.
Разделение весьма условное, да и промежуточные варианты тоже существуют, но вот сам язык позволяет использовать оба таких подхода — и старый, потому что куча кода написанная ранее должна продолжать работать, и новый, т.к. язык развивается и новые проекты лучше начинать используя последние возможности. Получается, что к php наверно всегда будут относиться с некоторым пренебрежением и презрением из-за староверов и недоучек, которые после установки вордпресса мнят себя обалденными специалистами, хотя сам язык и экосистема содержат все, чтобы писать понятный, быстрый и поддерживаемый код и эффективно решать задачи.
извините, веткой промахнулся
Ещё 3 года назад в твиттере я очень удачно ответил на твит Anthony Ferrara мыслью, которую поддержало довольно большое кол-во народу
С тех пор я только укрепился в своём мнении — очень больщое кол-во разработчиков PHP знают плохо — отбери у них фреймворк или дай им легаси проект в котором нужно разбираться почти с голым PHP — они как новорождённые слепые котята становятся, приходится тыкать моськой в мануал, где прямым текстом написаны очевидные вещи. Т.е. люди мануал если и читали, то вскользь.
С тех пор я только укрепился в своём мнении — очень больщое кол-во разработчиков PHP знают плохо — отбери у них фреймворк или дай им легаси проект в котором нужно разбираться почти с голым PHP — они как новорождённые слепые котята становятся, приходится тыкать моськой в мануал, где прямым текстом написаны очевидные вещи. Т.е. люди мануал если и читали, то вскользь.
Десять раз перечитал вот это:
Интересный способ согласования предложения.
Асинхронный curl'инг на локалхост (или даже другой веб-сервер) предоставляет неразделяемый (shared-nothing), копирование-в/копирование-из подход использования параллелизма.
Интересный способ согласования предложения.
Буду рад, если вы предложите более правильный перевод данной фразы, так как я действительно не очень понимаю, как правильно ее перевести.
Просто отправляя асинхронные запросы сами себе мы легко получаем параллелизм с изолированными состояниями и вызовами по копированию-восстановлению.
— Кстати у переводов должна быть соответствующая плашка.
— Кстати у переводов должна быть соответствующая плашка.
ПХП — говно язык, что уж тут поделаешь…
Последние года 3 пишу на PHP. Постоянно просматриваю блоги/твиты J.Pauli, nikic и других «папок». В последнее время просматриваю доклады Шипилева и других с jug/jpoint. Всегда жду новенького в хабе php…
Но вот эта «статья» не понятно, какую должна мысль донести. Холивара ради? И так хватает постоянных метаний фекалий из одного стана в другой. Неужели до сих пор люди не понимают, что к любому инструменту нужны «руки». А то потом разгребаешь божественный код адептов ror/django…
Поддался общей истерии и написал комментарий…
Но вот эта «статья» не понятно, какую должна мысль донести. Холивара ради? И так хватает постоянных метаний фекалий из одного стана в другой. Неужели до сих пор люди не понимают, что к любому инструменту нужны «руки». А то потом разгребаешь божественный код адептов ror/django…
Поддался общей истерии и написал комментарий…
Ну, отчасти да, ради того чтобы еще раз объяснить народу, что пхп решает задачи. До сих пор у массы программистов куча предубеждений и вирусов насчет него, и эта статья как антивирус для них.
Вторая причина — рассказ о Hack, статической типизации в мире пхп.
Статья для тех, кто думает, а не просто метает фекалии )) Вторые изменятся, когда станет вопрос о новой работе…
Господа, с php всё понятно — hi is alive.
В статье явно уклон идет больше на Hacklang, и на самом деле, после беглого знакомства — действительно не плох.
Собственно, может кто уже юзает реально в prodaction эту штуку, расскажет где можно захостить и какие подводные камни есть? Насколько я понял с оф.сайта под windows реализации нет?
В статье явно уклон идет больше на Hacklang, и на самом деле, после беглого знакомства — действительно не плох.
Собственно, может кто уже юзает реально в prodaction эту штуку, расскажет где можно захостить и какие подводные камни есть? Насколько я понял с оф.сайта под windows реализации нет?
Sign up to leave a comment.
Принимая PHP всерьёз