Да, утверждаю что PHP это грааль.

[macklakov]

Цитата:

Сообщение от ax_mct

Когда Google и PHP еще росли, а у MS был расцвет зрелости.

Ну, в принципе, да, соглашусь. ASP, для своего времени, была технологическим скачком.

[komar]

Цитата:

Сообщение от ax_mct

При отсутствии уникальности функционала вопрос "Чтобы что?"(c) - это об эффективности. Самый эффективный язык программирования - PHP

И ERP в повышении эффективности бизнеса - это невнятный результат за очень дорого.

А CRM, BI-планирование, e-commerce - прямая эффективность и возможно недорого.

Закон убывающей отдачи непобедим Основные плюшки, которые давала автоматизация бумагооборота, уже получены. Теперь уже вырисовывается стадия "приходится бежать со всех ног, чтобы только остаться на том же месте". То есть вбухивать кучу усилий на то, чтобы "начищать интерфейсы" у функциональности полувековой давности, бесконечно апгрейдя её на новые сервиспаки, туманные трёхбуквенные технологии, и т.п.

"В новой версии улучшен движок рисования кнопок на экране, и теперь кнопки рисуются с лучшим разрешением (для нормальной работы требуется установка MS Button Painting Server и MS Button Clicking Engine)". И на всём этом великолепии - MRP-алгоритмы 50х годов, реализация которых старательно перенесена с мейнфреймовых систем с точностью до структуры данных и вида отчётов

[ax_mct]

Цитата:

Сообщение от komar

Закон убывающей отдачи непобедим
...
И на всём этом великолепии - MRP-алгоритмы 50х годов...

Точно так. Поэтому фактор блестящего планирования ресурсов, замкнутый и влияющий на процессы в самой компании, без развития работы с клиентами и потребителями, это больше деньги на ветер. Как бы золотой унитаз.

MRP насытилось и заполнилось, сейчас управление время CRM, marketing, e-commerce, SEO и прочее - вот оно и настоящее и будущее. То есть то что ближе к людям и их деньгам. Время PHP

[AlexeyS]

что-то тема сравнения заглохла, подкину дровишек ))
.NET vs Java
Игра престолов JS и Java. Часть 1
Игра престолов JS и Java. Часть 2

[ax_mct]

Цитата:

Сообщение от AlexeyS

что-то тема сравнения заглохла, подкину дровишек ))
.NET vs Java
Игра престолов JS и Java. Часть 1
Игра престолов JS и Java. Часть 2

Посмотрел.
".NET vs Java" не впечатлило так как Java старше,
но "Игра престолов JS и Java" - это шедевр!! Спасибо

[gl00mie]

Где-то видел такое высказывание:

Цитата:

Инженер - это тот, кто может сделать за 10 центов то, что любой дурак сделает за доллар.

Мне кажется, такая логика отчасти объясняет и ситуацию с ERP. Да, возможно, функционал у многих систем более-менее сравнялся, да, возможно, спецмульки типа "большой красный кнопка для насяльника" тихонько скрючились под очередные аккорды кризиса - но бизнес из-за кризиса не перестал работать, не перестал искать возможности повышения своей эффективности. При этом бизнес зачастую уже не готов выкладывать тонны денег за супер-пупер систему, 80% функционала которой не будут использоваться, а оставшимися 20% пользоваться будет неудобно. Клиенты хотят более эффективного решения своих задач, более быстрой реализации проектов, хотят отработанных настраиваемых решений "из коробки", а не заказной разработки за их деньги, хотят перенести как можно большую часть выплат по проектам внедрения на период после запуска, а не вбухивать сразу тонну денег в те же лицензии, которые понадобятся в полном объеме лишь через год-полтора. Мне лично кажется, что в этом контексте ERP-системам еще есть куда развиваться.
Можно привести пример из области серверного ПО. Был Windows Server с давнишней, чуть ли не 30-летней историей, система развивалась, обрастала всё новыми сервисами, ролями, возможностями. Затем появились технологии виртуализации, все стали нарезать песочницы с Windows Server и размещать их рядом для выполнения разнообразных ролей. Но в итоге оказалось, что эти песочницы становятся слишком тяжеловесными и прожорливыми, имеющими слишком большую "поверхность атаки" для большинства сценариев использования и требующими постоянных перезагрузок для установки обновлений того, что реально не используется.
В результате появилась такая вещь как Nano Server. Это всё тот же Windows Server, но переделанный в конструктор, из которого можно собирать виртуалки с размером образа в 14 раз меньше, с количеством необходимых заплаток в 12 раз меньше и требующие за счет этого в 5 раз меньше перезагрузок, чем обычные виртуалки на Windows Server 2016.
Иными словами, появилась версия той же самой серверной платформы, способная решать задачи клиентов эффективнее, с меньшими требованиями к ресурсам и более дешевым обслуживанием. И это не кризис жанра (каких бы сервисов еще напихать в Windows?), а ответ на изменившиеся сценарии использования и приоритеты клиентов.

[Raven Melancholic]

А я тоже подкину дровишек.
Вот хочу утвердить, то PHP совсем не грааль. Ну мало ли что там делается на непонятном для заказчика сервере - результат виден же в том, что отображается в браузере.
Поэтому аксиома: грааль не PHP, а одностраничные приложения, использующие все новшества разных фрейморков java script.
ax_mct, ау!

[ax_mct]

Цитата:

Сообщение от AlexeyS

что-то тема сравнения заглохла, подкину дровишек ))
.NET vs Java
Игра престолов JS и Java. Часть 1
Игра престолов JS и Java. Часть 2

Цитата:

Сообщение от Raven Melancholic

А я тоже подкину дровишек.
Вот хочу утвердить, то PHP совсем не грааль. Ну мало ли что там делается на непонятном для заказчика сервере - результат виден же в том, что отображается в браузере.
Поэтому аксиома: грааль не PHP, а одностраничные приложения, использующие все новшества разных фрейморков java script.
ax_mct, ау!

Подымить сырыми дровами это интересно но никогда не тепло. Жарить надо на популярности, на базе клиентов конкретного продукта.

Назовите мне популярный продукт в сотни тысяч клиентов на этом таком модном и я завтра же буду жевать node.js и прочий гламур.

А пока Грааль существующего рынка - PHP. OK, для программиста-торговца или для тех кто хочет работать с любой точки мира.

"PHP" это конечно же не только PHP, а вся связанная эко-система для Full-stack программиста. Полный level-up после деградации с AX.

Java - тяжела для SMB, node.js - еще подросток, .NET - изгой, а Python'ы только претендуют на господство того же PHP.

Как вход в современное программирование - Грааль. Как язык сотен тысяч ваших потенциальных клиентов - Грааль. Как платформа вашего собственного бизнеса - Грааль.

Тот же Zoho - 25 миллионов пользователей. В пять раз больше чем у Microsoft CRM.
https://www.zoho.com/developer/?src=zoho

Я тут трое суток потратил чтобы SQL Server 2016 установить. Старею наверно. C PHP же это как в кроссовках бегать после тяжелых кирзачей.

[ax_mct]

Не взлетели пока одностраничные приложения хотя уже несколько лет усиленно пытаются.
Как понимаю одна из причин это не только усложненность их разработки но и отсутствие их поддержки со стороны того же Google. То есть ухудшение ranking/SEO без особых бенефитов.

20 мая 2016 Опыт перехода сайта на Single Page Application с упором на SEO
https://habrahabr.ru/post/301288/

Сыро и тяжело.
https://en.wikipedia.org/wiki/Single-page_application

А более или менее Single-page experience тот же Facebook (который на PHP) вполне себе реализует.

Грааль устоял

[Андре]

Наброшу-ка на вентилятор:

Цитата:

Как на PHP обработать миллион запросов в секунду? Если у вас не 100500 серверов. Никак.
Это практически невозможно, если нет какого-то бесконечного количества железа.

Проект ВКонтакте пошёл по развитию нагрузок — был написан транслятор из PHP в C++, который переводит весь код сайта в сишный код.

https://habrahabr.ru/post/322562/

[Logger]

Цитата:

Сообщение от Андре

Наброшу-ка на вентилятор:
https://habrahabr.ru/post/322562/

По такому пути не только в Контакте пошел, но и Фейсбук.

А некоторые пошли другим путем и остались очень довольный выбранным решением
https://habrahabr.ru/company/badoo/blog/279047/
Сэкономили 50 % железа.

Эхх. Если бы в аксапте так...
Ставишь 7-ю версию и высвобождается 50 % серверов.
Хотя возможно на терминальных серверах теперь и удастся сэкономить по сравнению с 12-й Аксаптой.

[ax_mct]

Цитата:

Сообщение от Logger

По такому пути не только в Контакте пошел, но и Фейсбук.

А некоторые пошли другим путем и остались очень довольный выбранным решением
https://habrahabr.ru/company/badoo/blog/279047/
Сэкономили 50 % железа.

Эхх. Если бы в аксапте так...
Ставишь 7-ю версию и высвобождается 50 % серверов.
Хотя возможно на терминальных серверах теперь и удастся сэкономить по сравнению с 12-й Аксаптой.

Прочитал. По идее самое первое предложение там

Цитата:

Меня зовут Лёша, я пишу на PHP.

должно произносится с толикой стыда. Но мне почему то кажется что даже этой толики не было Программисты с большой буквы.

[Bobkov]

Цитата:

Сообщение от Logger

По такому пути не только в Контакте пошел, но и Фейсбук.

Что конкретно вы имеете в виду? Куда именно пошел Фейсбук?

[ax_mct]

Цитата:

Сообщение от Андре

Ну, по хорошему, я не нашел для себя внятного ответа на вопрос, а зачем писать на PHP и потом транслировать в C++? Почему не взять тот же Go...

Go - многообещающий но все похоже что пока хорош только для узких мест, для отдельных технических продуктов. C выпуска Go (Golang) прошло 7 лет и возможно столько еще пройдет пока он станет конкурировать с граальностью PHP.

Цитата:

Сообщение от Bobkov

Что конкретно вы имеете в виду? Куда именно пошел Фейсбук?

Думаю речь была о своих JIT компиляторах.
Фейсбук - HHVM.
ВКонтакте - kphp.

Не трогать сам код, а совершенствовать среду исполнения/трансляцию - очень разумный выбор. Тот же мир .NET об этом может только мечтать.

[ax_mct]

Цитата:

Сообщение от Андре

Наброшу-ка на вентилятор:

https://habrahabr.ru/post/322562/

миллион запросов в секунду как основная проблема стартапов и SMB

Хорошая статья. PHP7 впечатляет, особенно если учесть количество вовлеченных людей и бюджет по сравнению с тем же .NET.

Десятки тысяч заказов в день хороший e-commerce на PHP держит. При желании можно просто создавать отдельные магазины по категориям товарам при том же основном URL. То есть масштабировать горизонтально до бесконечности. И пусть будет хоть 100500 серверов - не проблема при такой популярности

Цитата:

https://habrahabr.ru/post/322562/

Классная статья. Живой, динамичный мир.

Вдумайтесь:

Цитата:

В итоге пришлось обратиться за помощью к основному разработчику ядра PHP — Дмитрию Стогову.

В первую очередь он спросил, очищался ли кеш. Выяснили, что, действительно, в каждом случае так и было. Стало понятно, что проблема все-таки не у нас, а в OPcache. Мы быстро воспроизвели проблему и Дмитрий исправил ее в течение пары дней.

https://habrahabr.ru/company/badoo/blog/279047/

[Андре]

Ну, по хорошему, я не нашел для себя внятного ответа на вопрос, а зачем писать на PHP и потом транслировать в C++? Почему не взять тот же Go, который на данный момент уже имеет достаточно развитую инфраструктуру, хороший набор библиотек, позволяет разрабатывать со скоростью близкой к динамическим языкам программирования, но при этом получать нативный код, работающий близко к железу?

Догадываюсь, что в случае ВКонтакте ответ будет: "у нас уже много PHP кода, который нам уже просто страшно переписывать".

p.s.

Ну, то есть, я воспринимаю эту историю так: ребята начали писать на PHP (скорее всего потому что в то время, других альтерантив особо не было). Уперлись в ограничения языка и платформы.Эти ограничения были настолько непреодолимы, что они не смогли найти ничего лучшего, как транслировать свой код в другой язык (мне сложно представить худший вариант развития событий).

Опять же мои предположения, но скорее всего у них приложение- монолит (как принято было писать на PHP и как принято был писать в то время). Иначе бы просто отдельные узкие места были переписаны, а не транлированы.

[Андре]

Цитата:

Go - многообещающий но все похоже что пока хорош только для узких мест, для отдельных технических продуктов.

А дело в том, что я в "серебрянную пулю" вообще не верю. В арсенале разработчика должно быть несколько инструментов, а он уже в зависимости от задачи будет выбирать наиболее подходящий, исходя из условий задачи.

Например:

- Для микросервиса, в котом мне важна производительность и удобство развертывания я возьму Go. Его система типов и стандартная библиотека позволит мне реализовать узкие места с максимально возможой производительностью, а компиляция в нативный статически слинкованный код сведет деплоймент к копированию одного исполняемого файла.

- Если я пишу REST-сервис, задача которого сводится к работе с БД и отдачи JSON для SPA Web приложения - я возьму Node.js. За его асинхронность. И потому, что это действительно удобно, когда вся твоя команда может писать и читать - как front, так и end.

- Если заказчик корпоративный клиент и одним из условий является развертывание на Windows + IIS, то я предложу F#. С одной стороны я смогу использовать всем привычную библиотку .NET и порождать .NET совместимые сборки, а с другой стороны я смогу использовать статическую типизацию, вывод типов и Type Providers.

- Если задача содержит какие-то статистические вычисления, machine learning или что-то в этом роде, то я буду смотреть в сторону R - за его богатую библиотеку готовых протестированных алгоритмов. В крайнем случае - Python.

- Если я пишу что-то для себя, just for fun, то сейчас это будет Clojure. За его минимализм. За то, что он не плодит сущности сверх необходимого и поэтому, для меня, обладает некой внутренней красотой. При этом отсутсвие стаической типизации и мой внутренний параноик не дадут мне использовать его активно в production.

Но вот, при всей моей открытости к разным решениям и технологиям мне не приходит в голову случай, когда бы я стал использовать PHP. У любого языка, обладающего сильными сторонами, найдутся и слабые. Которые будут противоположностью и следствием его преимуществ. Язык, который хорош для всего - одновременно и плох для всего, что является следствием его универсальности.

[Андре]

Цитата:

Думаю речь была о своих JIT компиляторах.
Фейсбук - HHVM.
ВКонтакте - kphp.

Не трогать сам код, а совершенствовать среду исполнения/трансляцию - очень разумный выбор. Тот же мир .NET об этом может только мечтать.

А вообще, вся "граальность" PHP (по крайне мере в этом треде), основана вот на таких небольших, но постоянных передергиваниях. Не знаю, осознанно ты это делаешь, провоцируя других, или сам того не осознавая.

- kphp - не имеет никакого отношения ни к среде испольнения PHP, ни к JIT. Это просто транслятор.
- "Совершенствовать среду исполнения" - выбор разумный. Использовать транслятор - нет. Писать свой транслятор и потом поддерживать его - категорически нет.

Это даже не выбор, а последнее решение, когда мы никуда не можем свалить с платформы. Хороший пример тут JS (ES5): это единственный и безальтернативный язык, который понимают все браузеры и наличие трансляторов в JS превышает уже все разумные пределы

- Совсем не понятна фраза о мире .NET. Чему именно он должен завидовать ? Какие-такие хитрые оптимизации делает kphp при трансляции PHP в C++, что JIT из мира .NET должен вздрогнуть от восторга ?

[mazzy]

Цитата:

Сообщение от Андре

- Для микросервиса, в котом мне важна производительность и удобство развертывания я возьму...
- Если я пишу REST-сервис... я возьму Node.js.
- Если ... Windows + IIS, то я предложу F#.
- Если задача содержит какие-то статистические вычисления, machine learning или что-то в этом роде, то я буду смотреть в сторону R
- Если я пишу что-то для себя, just for fun, то сейчас это будет Clojure.

В принципе согласен с тобой.
Но справедливости ради надо отметить, что за это приходится платить огромную цену при интеграции этого зоопарка. Или на дублирование библиотек.

Но это отдельный разговор, похоже.

Цитата:

Сообщение от Андре

Не знаю, осознанно ты это делаешь, провоцируя других, или сам того не осознавая.

)))))))
А есть разница как он провоцирует? Если результат такой же.

[Андре]

Цитата:

В принципе согласен с тобой.
Но справедливости ради надо отметить, что за это приходится платить огромную цену при интеграции этого зоопарка. Или на дублирование библиотек.

На практике, как правило, получается, что один пункт - один проект/клиент. Если так не получается, то мы стараемся дробить решение на микросервисы (или просто сервисы), которые общаются друг с другом по документированному протоколу.

Но, вообще, мне часто приносят сторонние решения на оценку - "сможем ли мы это интегрировать/поддерживать" и по моим наблюдениям самые большие проблемы были именно с PHP решениями. Причем сразу на нескольких этапах - начиная от поиска грамотных специалистов и заканчивая анализом полученного кода.