Вступление от переводчика: очень давно веду разработку на PHP. Хоть я знаком с рядом других технологий и вижу некоторые недостатки PHP, но в целом я им доволен, и мне кажется несправедливым, что этот язык программирования подвергается нападкам чаще всего. Недавно нашел статью как раз на эту тему, думаю, позиция автора близка многим php-программистам, поэтому публикую перевод. Старался специально для корпоративного блога нашего проекта о платежных сервисах Web-payment.ru. Кстати, если вам понадобится подключить оплату на сайте — обращайтесь. Ну а далее перевод: Субъективное восприятие языков программирования не только порождает дискуссии среди скучающих программистов. Оно также влияет на принятие важных решений — прием на работу и финансирование.Эта фраза заставила меня всерьез задуматься над тем, как сообщество воспринимает PHP.
В недавнем выпуске JavaScript Jabber высказали пару замечательных комментариев о том, насколько люди предосудительны в вопросе выбора технологий, и как погоня за трендами отвлекает от работы над клевыми и нужными штуками.
Хотя Javascript активно занимает нишу PHP, особенно для начинающих разработчиков, есть несколько причин, по которым новые разработчики выбирают PHP:
- Вы хотите сделать сайт или приложение на виртуальном хостинге.
- Во всех книгах и видео, которые вы покупаете, так и или иначе работают с LAMP-стеком.
- Все вакансии для начинающих — для PHP-разработчиков.
Посмотрите, каким негативом окружен PHP в сообществе программистов:
- PHP Sadness: целый сайт, посвященный поиску «унылостей» в PHP.
- PHP: a Fractal of Bad Design: еще одна статья про то, какой PHP кривой.
- Why Does PHP Suck?: Еще одна похожая статья.
Цитаты по типу этой повсюду: «Тех, кто учит PHP, надо изолировать от общества».
Примечание переводчика: и Хабр не исключение.
После такого задаешься вопросом — а не выбрал ли я плохой язык?
Все написано на PHP
Может вы даже начнете сомневаться в себе из-за того, что поставили не на ту лошадь. Ведь всем, похоже, нравится Clojure, Haskell и JavaScript, но никому — PHP.
Давайте посмотрим в интернете, какие проекты все-таки используют PHP:
- WordPress
- Yahoo
- Wikipedia
- 4chan
Значительная доля крупнейших сайтов мира написана на PHP. Кажется бесспорным, что PHP — достойный и практичный язык для создания веб-приложений, но мы отвлеклись.
Сейчас не 2004 год
Много критики в адрес PHP основано на вещах, которых не было в языке, когда критикующий в последний раз на него смотрел — в начале нулевых.
Сегодня в PHP есть классы и нормальное ООП. Есть прекрасные фреймворки, например, Laravel и Symfony.
У PHP есть менеджер пакетов, который работает с огромным архивом опенсорсных пакетов.
У PHP есть прекрасные фреймворки для тестирования: например, PHPUnit для юнит-тестирования, Behat и Codeception для BDD.
Некоторые жалобы в вышеупомянутых статьях вполне обоснованы. В языке есть нестыковки, и, конечно, есть языки, в которых проблем меньше, но PHP выглядит очень даже ничего, если принять во внимание его возраст, гибкость и для чего он создавался.
Как это влияет на разработчиков
Ужасно обидно, когда тебя не принимают всерьез как разработчика несмотря на работу в серьезных проектах. Такое отношение серьезно вредит сообществу.
Часто кажется, что PHP-разработчики оказались заперты в замкнутых микро-сообществах. Из-за того, что в более крупных сообществах их не приветствуют, они часто устраивают собственные митапы, юзергруппы и конференции.
Забавная история
Порой это постоянное осуждение меня реально выматывает. Хоть я и знаю, что PHP — отличный язык, часто я думаю о том, чтобы совсем бросить писать на нем, лишь бы только больше не иметь дело с предубеждениями.
Когда я был моложе, я выглядел странно: с крашенными дредами, с пирсингом на лице и в залатанной одежде. Мне правда нравилось так выглядеть, но это ужасно утомляло.
Везде — во время занятий в колледже, на собеседовании на интерна, когда я начинал собственную компанию — мой внешний вид был постоянным отвлекающим фактором. В лучшем случае мне говорили, что для того, кто «выглядит так», я «на удивление профессионален».
Прошло 10 лет, но проблема та же — только отвлекает другое. «На удивление хорошо знаешь информатику для PHP-разработчика». Фу.
К сожалению, я не вижу подвижек в решении этой проблемы. Зачастую люди жалуются на PHP просто потому, что это модно. Но, к сожалению, конца этому не видно.
Это очень грустно. Мы оказались в ситуации «курица-яйцо»: если PHP-разработчиков постоянно унижать, они будут покидать сообщество, и в нем будет оставаться все меньше хороших PHP-программистов.
Статья переведена специально для корпоративного блога Web-payment.ru — проекта который, поможет подключить вам на сайте прием платежей или массовые выплаты. Обращайтесь!
Комментарии (334)
PerlPower
23.11.2015 12:13+1Ну на дворе уже правда не 2004 год, и нападок на PHP я почти не слышу. А слышу их обычно от тех, чье мнение никак не:
влияет на принятие важных решений — прием на работу и финансирование.
Starche
23.11.2015 17:22Это вам видимо везло. У меня периодически проскакивают клиенты, которым «знакомые разработчики» сказали, что всё, что написано на PHP — говно, и поэтому они против PHP в качестве основного языка проекта
aen
24.11.2015 08:56Такие клиенты есть на любой язык. Кто-то когда-то им что-то сказал. У меня недавно один клиент спросил про «перспективный javascript-фреймворк» под названием Bootstrap. Он был искренне удивлен тому, что мы его не используем. Ему тоже кто-то ляпнул какую-то чушь.
impwx
23.11.2015 12:29-5Статья целиком состоит из нытья по поводу того, что к PHP относятся как-то не так, как хотел бы автор.
«Всё очень плохо, и нужно лучше, а вот не получается, и что делать я не знаю».
Вместо написания статьи имело бы больше смысла молча принять к сведению все преимущества\недостатки и использовать эти знания при выборе инструментария для конкретного проекта.
NeonXP
23.11.2015 12:37+15Да пусть разработчики на «настоящих» языках и дальше снобствуют, нам-то что с того? Наоборот, приятно наблюдать, когда эти мегаджедаи явы и асп обсираются и срывают проект, который пилили по 2-3 года, а ребята на PHP переписывают его за полгода, с значительно меньшими издержками. Ну да, за то «У НАС ЖЫ ЫНТЫРПРАЙЗ!»
stalkerg
23.11.2015 12:56+2Ну к примеру Python явно не ЫНТЫРПРАЙЗ, но на нём можно писать ещё быстрее чем на PHP (банально строк меньше выходит :) ). Это я к тому, что с java/C# не только PHP сражается но и Python,Ruby,JavaScript и теперь Go.
NeonXP
23.11.2015 15:01-11А Ruby разве ещё жив?
Python? А что для веба на нём вообще написано? ИМХО, как язык скриптов и десктоп приложений он очень и очень хорош, но в вебе он как РНР в десктоп ПО.
JavaScript — согласен, нода очень и очень хорошо выстрелила, с интересом смотрю на неё. Как и на Go.
andrewnester
23.11.2015 15:08+4насчёт python вы сильно ошибаетесь, django, flask посмотрите для старта
NeonXP
23.11.2015 15:19-5Я знаю про них, но что на них особо пишут? Какие известные проекты? Даже на Ruby я могу вспомнить GitHub, а на Python ничего в голову не приходит из такого же уровня.
ilay
23.11.2015 15:42+7Instagram, Disqus и Pinterest — на Django
LionAlex
24.11.2015 10:29Disqus на Go теперь.
gaelpa
24.11.2015 10:55Go — всё-таки немного другая ниша. Это скорее язык на который переписывают проекты, когда им становится тесно в лимитах интерпретируемых языков, а не на котором начинают новое (если ты не гугл).
LionAlex
24.11.2015 11:10Не согласен. По мне, Go сейчас прямой конкурент PHP, Питону и Ноде на бэкенде.
Он простой, быстрый, компилируемый и имеет отличную поддержку конкаренси из коробки.
Конечно, по распространенности он не может сейчас бороться с вышеперечисленными языками, но за последний год растет очень быстро.
SamDark
24.11.2015 14:34Go — кокурент ноды для долгоживущих сокет-серверов и C для эффективной обработки массивов данных. По части веб я пока в нём конкурента не вижу.
Fesor
24.11.2015 15:28Go — кокурент ноды
уж извините, но нода для го не конкурент.
По части веб я пока в нём конкурента не вижу.
web это работа с вводом/выводом по большей части, и тут Go очень выгодно использовать.
Heckfi
23.11.2015 15:46+8Reddit, Dropbox, Yelp, Quora и многие други.
LionAlex
24.11.2015 10:30Dropbox на Go переходит.
ShadowsMind
24.11.2015 11:30Странно что не на Scala, у них же хороший евангелист там есть — Li Haoyi. Продуктивности этого чувака может позавидовать любой разраб… Хотя учитывая то, насколько Go активно пиарится и что он в разы проще, не удивительно что выбор пал именно на него.
andrewnester
23.11.2015 15:47+1bitbucket например ;)
дело даже не в этом, Вы просто очень категорично к python отнеслись
мне как PHP-разработчику очень интересно работать с python/django, там есть чему поучится и что можно было бы применить/уже применяется в PHP мире
к примеру, тот же Symfony вдохновлён как Spring, так и Django, и RailsNeonXP
23.11.2015 15:52От спринга в симфонии архитектура и похожий на гибернейт ORM, от джанго — похожий шаблонизатор. А что в Symfony от Rails? Всегда считал, что воплощение рельс на РНР — Yii.
SamDark
23.11.2015 16:22+2Yii 1.0 был воплощением рельс. 1.1 уже был прилично не похож. 2.0 унаследовал разве что философию.
VolCh
24.11.2015 00:04+1Symfony года на 3 старше Yii и сначала (до Symfony 2) влияние Рельс там очень ощущалось, собственно, заимствования идей и даже прямое портирование кода не скрывалось, например:
We have converted code written in other languages to PHP, like the Ruby on Rails helpers. But most of the time, we have implemented our own solution based on the community experience. This is the case for the new form framework, for which I borrowed a lot of ideas from two Python projects: the Django framework and the formencode library. In symfony 2.0, we will have a Dependency Injection framework, inspired by the Java Spring framework. Instead of reinventing the wheel over and over again, we can build better tools thanks to existing ones.
hudson
23.11.2015 21:08Я Flask распробовал — мне он даже больше Dajango понравился. Если не нужна джанговская админка — самое оно. А если надо event-driven, то Twisted.
defuz
24.11.2015 00:05Если нужна «джанговская» админка – есть flask-admin. К тому же, моя практика показывает, что именно джанговская админка с реальными задачами справляется не очень хорошо.
hudson
24.11.2015 09:13Да ну, я от джанговской админки как раз сбежал ) Не хочу пока фласк в джангу превращать. Хотя конечно зарекаться не буду.
bosha
29.11.2015 11:32Мне вот во Flask дико не хватает вменяемого RBAC :( У джанги он из коробки, и прям отлично работающий я бы даже сказал.
hudson
29.11.2015 16:33+1Ну flask все-таки и не fullstack фреймворк. Я не искал пока, может и управление доступом можно вменяемое подмешать во фляжку )
bosha
30.11.2015 09:23Разумеется, но всё таки это часто нужная вещь, и я весьма удивился, когда обнаружил, что flask community до сих пор не сделала ничего вменяемого :(
Есть flask-rbac, flask-security и что-то ещё было, но чего-то так же хорошо работающего как в джанге — я не видел.
zodchiy
23.11.2015 14:04+5Мой опыт говорит совершенно об обратной ситуации.
В данный момент в компании идет десяток проектов с привлечением внешних исполнителей. Внешние исполнители как интегрируют свои продукты, так и разрабатывают проекты с «нуля».
— Крупный и известный исполнитель со своим продуктом, сроки пролетели уже в несколько раз. Свой продукт на PHP, минимальная интеграция с API компании — аутентификация. Не могут 2 месяца наладить её. Последний перл — дайте нам API с возможностью читать ваш список пользователей постранично (пользователей всего 750, в списке только логины).
— Разработка ПО для терминала. Yii, php. 5 месяцев разработки функционала на 4 страницы (регистрация, каталог, товар, корзина). Ошибок столько, что плакать хочется, причем все детские, будто скрипткидисы пишут. Я каждый день просто тыкая в экран пальцем ловлю 2-3 ошибки. Это уже второй исполнитель по данному проекту обещавший, что сделает лучше и быстрее первого.
— Портал на Битрикс 24, писали-писали 1 год. Плюнули, поставили Sharepoint, за 1,5 месяца все сделали своими силами с помощью мышки и JS.
— Интернет-магазин, исполнитель со своим продуктом на PHP. Срыв сроков на 6 месяцев. Суд идет.
И это не за какой-либо период, это происходит прямо сейчас. Никто из исполнителей пишущих на C#/Java такого себе не позволяет.
Стоимость каждого из проектов, примерно, как квартира в Москве. Плюс ТЗ, танцы проджект-менеджеров, встречи-обсуждения. Это я к тому, чтобы не было мысли о том, что это делают школьники\студенты.
Думаю уровень знания, опыта и ответственности среднего программиста C# в «ЫНТЫРПРАЙЗ», выше чем программиста который работает только с PHP, в силу разноплановости разития, и не только из-за большего порога входа, тут и формы, и вэб, и по-настоящему большие проекты с коопразработкой. Где надо думать над архитектурой, и стиль — «оп-оп и в продакшн» просто не взлетит в силу того, что это просто не будет работать.
Я сам работал с PHP с 2001 по 2004 год. Но в 2005 ушел в ЫНТЫРПРАЙЗ с C#, правилами, паттернами, кодревью, оптимизацией, сетью и БОЛЬШОЙ ОТВЕТСТВЕННОСТЬЮ за написанный софт.
DigitalSmile
23.11.2015 14:53+8Поддерживаю. Мой опыт говорит о том же. Я не сомневаюсь, что есть хорошие программисты на PHP, которые следуют стандартам, паттернам и прочим «ЫНЫТЫРПРАЙЗ» штучкам, но та реальность с которой сталкиваешься каждый раз уныла, чуть более чем совсем.
SamDark
23.11.2015 15:10+1Я не следую «ЫНЫТЫРПРАЙЗ» штучкам (за исключением редких ситуаций, когда реально надо), но проекты сдаю вовремя и оттестированными. Что я делаю не так? :)
DigitalSmile
23.11.2015 15:31Я про то и пишу — таких как Вы, меньшинство, к сожалению. Я в своей практике очень редко встречался с грамотными PHP-шниками.
DigitalSmile
23.11.2015 15:55Ох, извиняюсь, прочитал неправильно, на заметил «не» :)
Мое мнение, что каждой задаче — свой инструмент. Это касается и языков и паттернов и методологий. Если нужно забабахать страничку в вебе или интернет-магазин, то почему бы не использовать PHP (даже без ООП, обожемой, что я говорю!), если он Вам по душе. Но все-таки на серьезные проекты, где требуется жесткий контроль за качеством выходного продукта, лучше взять тех же джавистов, чем пхпшников, имхо. Так сложился рынок…
Хотя опять же оговорюсь, если у Вас команда толковых PHP-шников, в которых Вы уверены, то почему бы и не использовать их :) Я вот таких не встречал, о чем написал выше.SamDark
23.11.2015 16:21+7Я пять лет писал веб на J2EE. Это ужасно (по крайней мере было) по сравнению с PHP. Мордочки больших Java-проектов и то пишут на PHP потому что развивать их так проще: деплой проще, отлаживать проще, из коробки больше всего. С нормальных фреймворком даже на косяки PHP не наступаешь. Вообще красота!
Контроль не зависит от языка. Тут либо самодисциплина, либо грамотный управленец. Раздолбаев на Java не меньше, просто они лучше шифруются за ЫНЫТЫРПРАЙЗ-ом и паттернами.DigitalSmile
23.11.2015 16:33Ваша правда, если мы уж затронули тему веб мордочек, то джава тут явно не на первом месте :)
А вот по контролю не соглашусь. PHP тут скорее исключение и именно из-за сложившейся конъюнктуры. В подавляющем большинстве PHP-программисты менее квалифицированы, чем Java-программисты. Сужу по людям и конторам, где работал, хотя понимаю, что мне могло тупо не везти :)poxu
23.11.2015 16:37Ваша правда, если мы уж затронули тему веб мордочек, то джава тут явно не на первом месте :)
У джавы тут все великолепно. Но часто получается так, что веб пилят те же программисты, что и всё остальное. У них громадный опыт программирования в их области и практически никакого в веб. Результат — соответствующий.SamDark
23.11.2015 18:09+1Ну не знаю, меня всегда билд и деплой ради горстки HTML вымораживал. Я из за этого на кофе подсел, всё-равно делать нечего пока билдится…
poxu
23.11.2015 19:18Ради HTML я не билдил ничего никогда. Даже jsp в servlet api древнем автоматом подливаются. Для тяжёлых случаев есть JRebel :).
SamDark
23.11.2015 19:38+1Ну, не пихать же какую-никакую логику в JSP? Так и так что-то да будет. Из базы данные выбрать, рассортировать, показать, юзера залогинить…
webkumo
25.11.2015 09:27+1Мне интересно, вы действительно не знаете про velocity, freemarker, thymeleaf и прочие шаблонизаторы? Которые для той самой джавы и созданы (+ некоторые портированы с других игроков, например handlebars), И как раз, чтобы бекэндщикам не приходилось гнать говённый UI (который они всё равно не умеют готовить).
SamDark
25.11.2015 14:32Конечно, сейчас в Java всё немного удобнее стало, но когда я последний раз делал веб на Java, Thymeleaf и FreeMarker точно не было. С Velocity 1.5 как-то работали. Также припоминаю XSLT в качестве шаблонизатора. Голый PHP на тот момент уделывал их по удобству.
VolCh
25.11.2015 09:59+1Контроль не зависит от языка. Тут либо самодисциплина, либо грамотный управленец. Раздолбаев на Java не меньше, просто они лучше шифруются за ЫНЫТЫРПРАЙЗ-ом и паттернами.
Вот поддержу. Просто и управленцам (им легче контролировать), и разработчикам (им легче скрывать косяки) повезло, что эталонная реализация Java — компилятор, что Java — язык с сильной статической типизации и, как следствие обоих пунктов, некоторые классы ошибок просто не могут попасть в исполняемый файл. Собственно не только Java касается, но и всех сильнотипизированных компилируемых языков — на них невозможно создать исполняемый файл с ошибками типизации и просто грубыми синтаксическими ошибками.
Если бы обычная практика разработки на компилируемых языках не включала обязательный статический анализ, то вряд ли что-то сильно бы отличалось от того же PHP, лучшие практики разработки на котором мало отличаются от практик той же Java. Включая статический анализ кода перед не то, что деплоем или коммитом, а даже запуском, в который (анализ) входит в том числе и проверка явного объявления переменных и типов (PhpDoc), и проверка на использование неявного приведения типов.
bosha
29.11.2015 11:36Мое мнение, что каждой задаче — свой инструмент. Это касается и языков и паттернов и методологий. Если нужно забабахать страничку в вебе или интернет-магазин, то почему бы не использовать PHP (даже без ООП, обожемой, что я говорю!), если он Вам по душе. Но все-таки на серьезные проекты, где требуется жесткий контроль за качеством выходного продукта, лучше взять тех же джавистов, чем пхпшников, имхо. Так сложился рынок…
Вот в этом и проблема основная — PHP разрабы пытаются все написать на нем…Fesor
29.11.2015 12:49+1и в чем тут проблема? я думаю если бы средний php разработчик просто так взял java/scala то все бы пошло куда более плохо.
А то что php разработчики используют для решения задач язык который они хорошо знают, то проблемы нет. Другое дело что большинство свой язык не очень хорошо знают.bosha
29.11.2015 13:32Такому среднему типичному PHP разработчику бы пришлось разобраться со статической типизацией, нормально начать использовать эксепшены и разобраться с ООП. Так что спорно. Весь этот набор необходимых сопутствующих знаний прокачал бы его.
Fesor
29.11.2015 14:20+1Весь этот набор необходимых сопутствующих знаний прокачал бы его.
Для всего этого не надо менять язык или пытаться пописать на Java (хотя это очень полезный опыт, вопробовать пописать еще на парочке языков).
Более того, вероятность того что человек разберется с ООП и т.д. только потому что возьмет java примерно такая же как и с PHP (я знаю достаточно java разработчиков которые понятия не имеют о SOLID или о том как работать с исключениями, а java 1.8 вообще позволяет в этом плане не особо заморачиваться).
Тут проблема в том что люди не знают что учить (хотя как мне кажется просто не хотят).
sck_v
23.11.2015 14:54+5функционала на 4 страницы
Стоимость каждого из проектов, примерно, как квартира в Москве.
Немного странно, не находите?jrip
23.11.2015 15:04+11Да там небось обычная ситуация, «а ну давай те вон тех наймем на пхп, они занедорого напишут».
А далее парят мозг, каждый день что-то заставляя менять, либо внезапно окажется, что проблема вообще не в пхп, а в том что кто-то не сказал, что верстка под мобильные устройства, например нужна.
Ну да так повелость, что парни на с# — java обычно и берут сильно больше и договор грамотно составляют, так что бы потом на просьбу «поиграться со шрифтами» выставить нифиговый счет.
Только это не проблема в языке, это проблема в мозгу всех причастных.
NeonXP
23.11.2015 15:16+11В ЫНТЫРПРАЙЗЕ так принято. 100500 совещаний менеджерья всех уровней, и за неделю до дедлайна дают Васе, который эти 4 странички напишет и получит свои скромные 50тыр/мес. А квартира разойдется по этим милым и прекрасным эффективным менеджерам.
NeonXP
23.11.2015 15:13+4Писал большой развернутый коммент, но, к сожалению, не ушел :(
Если кратко:
По первой части: дебилы есть везде, это не аргумент. У вас свой опыт, у меня свой. Я чаще встречал идиотов, которые ради трехстраничного магазинчика с криком «ОЛОЛО, ЫНТЫРПРАЙЗ» брали J2EE/Spring/ещё-какое-то-страшное-говно и весело залипали на полгода-год. Очень частая и грустная история.
Offtop: ПО для терминала на РНР? ЛОЛШТО? Как? Зачем? Почему? Они бы ещё, ***, микроконтроллер на РНР программировали! При всей моей необузданной любви к РНР, он — только для веба и смежного (ну сервисные скрипты/демоны для этого проекта)
По второй части, как это коррелирует с языком? Неужели язык запрещает продумывать архитектуру, методологии? Неужели язык заставляет делать «оп оп и в прод»? А взяв какой-нибудь богомданный C#/Java программист тут же превращается в крутого синьёра, который пишет код, взглянув на который Дейкстра и Кнутт в обнимку будут плакать от умиления?
В последней части вы подставились. Вы всерьез думаете, что за 10 лет ничего не изменилось и мы всё так же барахтаемся в своём болоте? Для справки за последние 10 лет мир РНР изменился до неузнаваемости: появились нормальные стандарты кодирования, отличные инструменты, фреймворки, способные дать под зад этим разным спрингам.
Вроде ничего особо не забыл.zodchiy
23.11.2015 15:23Я написал про опыт, свой опыт, он говорит обратное к
когда эти мегаджедаи явы и асп обсираются и срывают проект, который пилили по 2-3 года, а ребята на PHP переписывают его за полгода,
А взяв какой-нибудь богомданный C#/Java программист тут же превращается в крутого синьёра, который пишет код, взглянув на который Дейкстра и Кнутт в обнимку будут плакать от умиления?
Я считаю, что скрипткиддис от PHP может спокойно и долго работать, а программисту от «энтерпрайза» не дадут второго-третьего шанса. Там рулит бабло.
В последней части вы подставились. Вы всерьез думаете, что за 10 лет ничего не изменилось и мы всё так же барахтаемся в своём болоте? Для справки за последние 10 лет мир РНР изменился до неузнаваемости
Я за то, чтобы бить гвозди молотком, а не микроскопом. У PHP свой мир, где лучше него нет, а у C#/Java, свой мир. И я пишу о том, что каждый инструмент хорош для того, для чего его создавали. Я понимаю, можно и большие решения на GUI под окошки писать на JS. Но, зачем?NeonXP
23.11.2015 15:34Дык я же согласился, что опыт у всех разный, у меня свой, у вас обратный. Тем не менее, и тот и тот есть в реальности.
Я считаю, что скрипткиддис от PHP может спокойно и долго работать, а программисту от «энтерпрайза» не дадут второго-третьего шанса. Там рулит бабло.
Эм, откуда там вообще тогда есть программисты, если там такая Спарта? Неужели там только эльфы, которые не совершают (и не совершали никогда) ошибок от слова «совсем»? Выходит, так. Или где-то меня пытаются обмануть ;)
У PHP свой мир, где лучше него нет
Именно, шулай! И этот мир — веб разработка. Я тоже за то, чтобы РНР из этого мирка никуда не перелезал. Но и за то, чтобы в этот мирок не лезло отребье из других областей.
Crandel
23.11.2015 16:06-19Как раз из веба одно отребье в пыхе и торчит. Более серьезные вещи делаються в том же руби, Python и тд. Посмотрите хотя бы биржи фриланса, как платят пхпышникам и как всем остальным. У пхпе ниша — одностраничники и сайтики за 2 недели ну и легаси, которое обставляют костылями типа hack, чтобы хоть как то справляться с нагрузками, смиритесь уже с этим. Как хорошо, что я перешел на Python
SamDark
23.11.2015 16:25+4Вам ещё раз дать список проектов, сделанных на PHP, и зарплаты в этих проектах?
Crandel
23.11.2015 16:29-3Это все легаси, если бы у них был выбор все переписать с нуля, я уверен больше чем на 100% что они бы выбрали другой инструмент. Они вынуждены работать с этим. тот же фейсбук и контакт лагают чаще чем раз в неделю. Если бы не балансировщики и стопицот серверов — давным давно пролетели
shoomyst
23.11.2015 16:34+5spotify.com is powered by the @symfony framework and many great packages from http://packagist.org using Composer by @seldaek
Странные ребята, и rails уже был, и django, а эти дурни опять полезли в этот пыхапе!11
SamDark
23.11.2015 18:13+12gis, wikimart, Innova, Alawar, flamp, runet-id, Etsy, mailchimp… можно вечно продолжать. О, ещё хабр, кстати ;)
blog.mailchimp.com/ewww-you-use-phpShadowsMind
23.11.2015 18:43-2Вы так говорите, как будто у тех же 2gis сам продукт написан на PHP. Вы хотя бы, прежде чем людей вводить в заблуждение, посмотрели хотя бы вакансии этих фирм, а если уж совсем не лениво то блоги их почитали бы. Там от всего что написано, на PHP поди одна страничка, а не окрепшие умы будут думать, что Innova Линейку на PHP написала(хотя они вообще лишь локализаторы) :-D
SamDark
23.11.2015 18:58+1Ну да, у 2gis API на PHP и Yii. Я у команды был в офисе в Новосибирске, всё видел собственными глазами. Вы же не думаете, что я утверждаю, что у них приложение для iOS на PHP написано? :)
У Innova весь веб на PHP и Yii. Линейка, естественно, нет :)ShadowsMind
24.11.2015 13:30Да в курсе про, то что у них API и контент для юзеров PHP отдает. Но не зря же у них постоянно вакансии C++/Java разрабов в интернетах висят. Плюс ко всему на глаза попадалась часто фразы в духе «2Gis, scala developer».
Вообще такой подход многих фирм — это достаточно логичный выбор. Они понимают, что им нужно N количество девелоперов чтобы сделать отдачу контента например, и знаю что лучше взять язык X, даже не по соображениям продуктивности, а по соображениям где они будут брать этих самых девелоперов.SamDark
24.11.2015 14:37Они же занимаются не только отдачей готовых данных. Все эти данные они ещё и собирают. Огромный штат картографов и контентщиков (не знаю, как правильно назвать тех, кто уточняет данные по фирмам). Надо тучу утилит, чтобы всё это приятно вбивать и обрабатывать. Ну и, скорее всего, тяжёлую обработку они делают сейчас не на PHP. Это нормально.
alff31
23.11.2015 21:26+2Хабр это был первый проект Денискина, другие вот проекты уже делали на рельсах.
Хабр на PHP, на RoR brainstorage.me, hantim.ru, freelansim.ru и autokadabra.ru.
Toster.ru тоже на PHP.
habrahabr.ru/company/xakep/blog/203094/#comment_7028358
shoomyst
23.11.2015 16:27Поподробнее расскажите про серьезные вещи
Crandel
23.11.2015 16:35-7Youtube, Flickr, Instagram — мало? Это все на Python написано
SamDark
23.11.2015 18:14+2Flickr вроде всегда был на PHP: highscalability.com/flickr-architecture
Crandel
23.11.2015 18:18-1Перепутал с Disqus. А еще есть Pinterest, Reddit, Quora, DropBox, Bitbacket
SamDark
23.11.2015 18:23Никто не спорит, что питон был очень популярен когда Django был трендовым. Такое случалось со всеми платформами и не удивительно, что есть написанные практически на любой нормальной платформе отличные проекты.
andrewnester
23.11.2015 18:30+1а почему именно был?
SamDark
23.11.2015 19:01+1Потому что сейчас он не трендовый, а просто отличный и самый крупный фреймворк на питоне. То же с RoR. Во времена «блога за 15 минут» на рельсы бежали все сломя голову. Потом мода прошла, люди поняли, что рельсы код за них писать не будут и успокоились. Рельсы стали просто замечательным руби-фреймворком, но сломя голову на них бежать перестали.
Сейчас в тренде нода, хотя уже самый пик спадает.andrewnester
23.11.2015 19:13+3сейчас тренд Go ;)
SamDark
23.11.2015 19:39+1Да, но тоже пик проходит потихоньку. Go у нас прижился как очень эффективная молотилка данных.
NeonXP
23.11.2015 16:45+4Почему мы должны смиряться? Потому что какой-то странный человек так сказал? Ха-ха-ха. Нет уж, с вашего позволения, продолжу делать прекрасные большие проекты на PHP/Symfony 2.
Crandel
23.11.2015 18:28-2Потому что называть других людей отребьем вызывает у меня слишком бурную реакцию, вот и не сдержался, теперь сожалею
NeonXP
23.11.2015 21:48+1Да я вообще-то отребьем назвал технологии…
Но и за то, чтобы в этот мирок не лезло отребье из других областей.
Мир РНР — мир [технология]. В этот мир не лезло что? Отребье [технологии] из других областей. Причем тут люди? То то я ваш коммент понять не мог, про то какое отребье в РНР торчит.
VolCh
24.11.2015 00:15Offtop: ПО для терминала на РНР? ЛОЛШТО? Как? Зачем? Почему?
Что такое современный терминал знаете? Обычная персоналка с купюроприемником и сенсорным экраном. Для его задач ресурсов более чем достаточно, чтобы поднять обычную десктопную ось, запустить в ней браузер и какой-нибудь веб-серверный стэк (включая даже «взрослую» БД) в практически однопользовательском режиме. Почему не «LAMP»? Работа с купюропреемником (через либы вендора) инкапсулируется в расширении PHP, или отдельном относительно тупом сервере на, например, питоне и большинство задач по интерфейсу может решать обычный «сайтостроитель».NeonXP
24.11.2015 01:04Знаю, даже делал оболочку к нему (но не на РНР). Вопрос остаётся. Разве не проще взять какой-нибудь nw.js в kiosk-mode (и да, к купюроприёмнику там интерфейс есть через расширение node.js). Или, о ужас, написать нативную десктоп приложуху на практически чём угодно.
Любой, даже самый двинутый «сайтостроитель» может в js, так что вариант с nw.js вполне может взлететь. Да даже есть всякие извращения типа для созданий «нативных» приложений на РНР, для самых упоротых.
Вот только зачем там веб-фреймворк то? Не вижу ни одной объективной причины.VolCh
24.11.2015 02:32Кому проще, а кому нет. Сроки, опять же. Ещё есть такое слово «унификация». Как правило, у компании есть сайт, где можно провести те же операции, что и в терминале только вместо кэша карты и электронные деньги — писать два раза одну логику? Или и сайт делать на node.js? Не вижу ни одной объективной причины писать сайт платежной системы на node.js. А обёртку купюроприемника вполне может быть на чём угодно, включая node.js. А внутренний сервер логично писать на веб-фреймворке, коль скоро принято решение, что интерфейс будет в браузере. Какой фреймворк на каком языке — это уже ситуационные решения.
hudson
23.11.2015 21:10+2Проекты в конечном итоге делают не инструменты, их делают люди. Одна команда делает на технологическом стеке «А» быстро и качественно, а другая на стеке «Б» делает кое-как. А третья и «А» не умеет готовить… Так было и есть. И веротяно еще не изменится какое-то время.
Fesor
23.11.2015 22:38У меня есть другой опыт. Был серьезный проект для очень крупной компании. Поскольку «php-ники ж не шибко умные, не серьезно все это» взяли джависта. Что такое юнит тестирование — не знаем. Зачем нужно писать тесты — не знаем. SOLID — что это, зачем это все надо.
Сам по себе проект простой — если упрощать что-то типа сервиса заявок, кто успел того и заявка. Работать все это должно было в условиях плохой сети так что конфликты возникают часто.
Итог — срыв сроков, постоянные регрессии, при синхронизации и возникновении конфликтов происходят баги которые разработчик не мог пофиксить больше месяца. Ну и опять же когда фиксил что-то одно ломалось что-то другое. Дошло до того что посадили рядом php разработчика который хотя бы функциональными тестами это дело покрыл.
p.s. Я лично за 6 лет ни разу не видел адекватно написанного проекта на Yii. Как-то так сложилось (сам 3 года работал с ним и знаю его хорошо, сам ходил по всем возможным граблям), что проекты как только приобретали определенную сложность (что-то сложнее CRUD-а, например интернет магазин со специфичной бизнес логикой или биржа труда) разработчики сразу же превращали код в мессиво (и сам таким грешил, ибо фреймворк сам по себе потворствовал этому).
Я хорошо помню один комментарий в ишус трекере Yii (увы не дословно) при обсуждении добавления IoC или контейнера зависимостей: We don't need some fancy patterns. Он очень хорошо передает суть.
исполнитель со своим продуктом на PHP
А вот это уже проигрыш сразу. Если разработчик собирается использовать решение которое поддерживать может только он то от него надо бежать.webkumo
24.11.2015 02:01+1Т.е. вы, сами не обладая экспертизой в Java за каким-то «надом» наняли отдельного java-программиста (о навыках которого не могли судить)? И это «серьёзный проект»? Да с тем же успехом вы могли фрилансера нанять! Никаких гарантий, если нет опыта работы с конкретным человеком. В целом же — самостоятельный проект требует квалификации близкой к сениору — у большинства мидлов просто не хватит опыта, чтобы во всех узких местах пролезть.
Fesor
24.11.2015 02:05Т.е. вы, сами не обладая экспертизой в Java за каким-то «надом» наняли отдельного java-программиста
Так не я же лично, так решило начальство. Как проходил найм я могу только догадываться. Да и прособеседовать Java разработчика я например могу, но меня к этому вопросу привлекли уже когда все пошло не так.
Никаких гарантий, если нет опыта работы с конкретным человеком.
Есть еще проекты различной сложности. Скажем вы могли успешно сотрудничать с человеком в рамках простых проектов, а чуть сложнее и начинется веселье.
HaruAtari
24.11.2015 02:04Fesor Не сочтите за рекламу. Вот часть проектов над которыми мне пришлось работать. В основном это ERP системы и им подобные. Все написаны на Yii: часть на первой версии, часть на второй. Ни разу не испытывал проблем с архитектурой.
Да, у фреймворка есть архитектурные проблемы (особенно у первой версии, у второй почти все нормально). Но они никак не мешают строить грамотную архитектуру своего кода.
И сейчас новые пректы я пишу именно на нем т.к. этот фреймвокр, на мой взгляд, предоставляет наилучшее соотношение возможностей и простоты. В нем все очень хорошо и «правильно», но без фанатизма.
Для справедливости отмечу, что я не использую его для генерации html сайтов (разрабатываю только rest api) и про эту часть фреймворка сказать ничего не могу.яFesor
24.11.2015 02:11Ну… я как бы не вижу ничего сложного в этих проектах (в плане архитектуры). Если у нас там чисто REST/HTTP API, мало бизнес логики (по сути у вас там только работа с данными, выборки из базы, возможно CQRS какой-нибудь можно вкатить). То есть конкретно Yii тут мало палок в колеса может поставить (только active record и то сомневаюсь).
Я же говорю о проектах где например есть десяток сущностей с кучей отношений между друг дружкой, с кучей бизнес правил и т.д.HaruAtari
24.11.2015 02:28Из-за NDA не могу там указать подробности работы. Открыто могу расскащать про перую работу в списке — самую свежую.
Сейчас уже 12 крупных модулей, которые с одной стороны полностью изолированны друг от друга, с другой тесно взаимодействуют. Отключение любых из них является штатной ситуацией. Поддерживаются различные версии, кастомизация, версионирование данных. В базе под 500 таблиц. Программных сущностей чуть меньше. Содержит около 2000 классов. Архитектура чистая, гибкая, устойчивая к сбоям. Система работает распределенно на нескольких серверах. Думаю, это можно назвать сложным пректом.
Остальные проекты не такие сложные но по несколько десятков взаимосвязанных сущностей в них есть.Fesor
24.11.2015 02:34Я не спорю что на Yii можно писать нормальные поддерживаемые приложения, особенно если само приложение будет изолировано от фреймворка (хотя бы частично). И уж темболее можно писать адекватно на Yii2.
Я говорю о среднестатистических разработчиках код которых мне приходилось ревьювить. И на проектах чуть сложее интернет магазина уже начинаются проблемы.
Что говорить о том что я нахожу XSS уязвимости в каждом проекте на Yii который приходит ко мне на ревью.HaruAtari
24.11.2015 02:44+2Я лично за 6 лет ни разу не видел адекватно написанного проекта на Yii.
Хотел чтобы вы увидели хоть один :)
annenkov
26.11.2015 22:18> Что говорить о том что я нахожу XSS уязвимости в каждом проекте на Yii который приходит ко мне на ревью.
Намекните плз где чаще всего они находятся?Fesor
26.11.2015 23:38везде где выводятся значения вбиваемые пользователями. Начиная с имени фамилии и заканчивая поиском, комментариями и т.д. Просто не экранируют вывод. + встроенные js библиотечки в Yii (или в экстеншенах) тоже могут чего-нибуть выводить без экранирования.
Ну то есть это не проблема конкретно Yii, а проблема отсуствия шаблонизатора с фильтрацией вывода по дефолту. Средства что бы делать все ок есть в самом Yii но про них не знаю и не пользуются. Так же частенько просто забывают.
Для новичков это черевато проблемами. Им вообще бандаж нужен, а не язык или фреймворк который позволяет все на свете и не ругает ничего.annenkov
26.11.2015 23:53понятно, спс, в моделях валидатор со strip_tags назначаемый на любые вводимые строковые значения уже видимо решает эту проблему? плюс в стандартных виджетах выводятся строки по умолчанию с экранированием, хотя где выводятся строки без виджетов проследить непросто конечно
Fesor
27.11.2015 00:09вообще я лично считаю это неправильным, менять пользовательские данные. Вдруг человек хотел поделиться в комментариях снипетом кода? Всякое бывает. А тут взяли и порезали. Ну и да, разработчик может и забыть это сделать. Ну и опять же, возможны ситуации когда должны быть разрешены отдельные теги (хотя через strip_tags это можно захэндлить).
Экранирование должно происходить при выводе и лучше автоматически. Об этом даже говорится в документации, правда удобного решения проблемы как бы не приводится. Вариант что использовать, старый добрый htmlspecialchars или какие-то отдельные библиотеки-санитайзеры.
В Twig например экранирование происходит по дефолту, если мы не задали при выводе других параметров. Стандартный вывод значения ({{some.prop}}) прогонит значение через фильтр. При желании мы можем подифицировать параметры экранирования через фильтры (raw и т.д.)annenkov
27.11.2015 00:16Про Twig — также работают все стандартные виджеты, тоже по умолчанию используется формат с экранированием, но можно его изменить. Для вывода вне строчек используем функцию шорткат — коротко-удобно и настраивается в одном месте, но опять же конечно надо постоянно следить, чтобы никто не забыл обернуть вывод…
annenkov
26.11.2015 23:55> Им вообще бандаж нужен
как вариант — тим лид хорошо помогает для начала, но не всем с этим везет конечно :)Fesor
27.11.2015 00:02+1тим лид это один человек, а когда технология ограничивает и учит правильным вещам это намного лучше. Когда уже привыкаешь к хорошим практикам и осознаешь почему они хорошие, тогда уже можно потихоньку снимать ограничения.
msfs11
24.11.2015 14:40> Если разработчик собирается использовать решение которое поддерживать может только он то от него надо бежать.
Вообще, если исходный код передается заказчику, то ничего страшного. И, у меня есть положительный опыт: я работал в vipro.ru мы писали свою CMS, где все было сделано для людей. Битрикс рядом не валялся.
olegf13
24.11.2015 11:38+3Может вам просто стоит начать искать команды проф. разработчиков для таких проектов, которые вы упоминаете, или сменить место поиска (если задачи на команду не тянут)?
А то возникает чувство (поправьте, если я не прав), что вы пытаетесь в той тусовке, где 90+% заказов «поправить что-то на вордпрессе» найти людей, которые не имеют опыта корпоративной разработки.
vba
23.11.2015 17:31Честно скажу что мне встречались обратно противоположные сценарии, когда php разработчики превращали проект в серое болото, тут скорее у кого от куда руки растут. Хотя в php еще пару лет назад можно было встретить больше полоруких разработчиков, маслом им что ли там намазано.
psylosss
23.11.2015 12:51Интересно, а есть ли (хотя бы в планах) что-то типа форка РНР, который бы не обеспечивал обратную совместимость, но убирал бы значительную часть костылей древности?
stalkerg
23.11.2015 12:58Такой язык никому не нужен. Собственно часть «нападок» на PHP в целом из-за ощущения, что это lagecy. Если в PHP поломают капитально совместимость, то другие языки стоять и ждать не будут.
psylosss
23.11.2015 13:00Именно поэтому я говорю про форк, а не ставлю вопрос «когда-нибудь в РНР уберут уже эту strpos-substr?».
Такой язык никому не нужен.
Это личное предположение или результат какого-то исследования?stalkerg
23.11.2015 13:13Это личное предположение или результат какого-то исследования?
Результат личного исследования. Новому PHP надо будет сражаться со старым PHP + с Python, Ruby, Go, JS, C# и т.д.annenkov
26.11.2015 22:21Python 3 — все таки решились, там много не совместимых нововведений, из-за этого на него очень неспешно переходят конечно, но процесс идет
stalkerg
27.11.2015 11:49При том, что комьюнити Python с трудом можно назвать консерваторами… у PHP мне кажется с этим будет всё хуже, но тут уже моё личное ИМХО.
sefus
27.11.2015 11:59Python 3 вышел 7 лет назад, и как широко он используется сейчас?
Через 7 лет после выхода PHP 5.0 он был уже на 90% сайтов.stalkerg
27.11.2015 12:20Я не понимаю как ваш вопрос связан с моим комментарием.
sefus
27.11.2015 12:34Это был риторический вопрос. По этой статистике только 1% сайтов на Python использует третью версию.
stalkerg
27.11.2015 12:53Это тут причём? У PHP разве был рывок когда они поломали полностью обратную совместимость при наличии конкурентов?
ЗЫ интересно как они считали? Я уже как 3 года использую тройку.
Fesor
27.11.2015 14:33у PHP все очень жестко завязано на обратную совместимость (и я не считаю что это плохо). Просто иногда читай php internals начинаешь расстраиваться, ибо некоторые люди сводят хорошие идеи к обсурдным. Но это так же нормальное явление в большом комьюнити. Всегда найдутся недовольные.
Stepanow
23.11.2015 13:01+3Только вчера слышал тот-же вопрос про Java. Опыт Python показывает, что это очень опасно для языка. Хотя «эффект бега с развязанными шнурками» тоже очень неприятная штука. Возможно, самый правильный путь — не остановиться и завязать шнурки, а потихоньку выдавливать «древности» в deprecated и по одной запрещать в каждом следующем релизе. Тогда сразу много всего переписывать не придётся, исправления старого кода будут простыми и вреда будет меньше, чем пользы от отказа от этих вещей. В этом русле собственно и идёт развитие PHP.
psylosss
23.11.2015 13:04Отлично, что есть чей-то опыт, с которым можно сравнить! Согласен, вероятно, это не самый лучший сценарий, но… если бы оно уже было, я бы как минимум попробовал. Очень нравится как развивается РНР в последнее время — и направление, и темпы.
stalkerg
23.11.2015 13:21+2Python к слову вроде наконец до вязал почти все шнурки и троечка становится основой новых проектов. Но мне больше интересен Pyston.
PQR
23.11.2015 15:52+1Не форк, но язык очень похожий на PHP и при этом без костылей: Hack — уже production ready.
Есть ещё JPHP — PHP под JVM, но не уверен насчёт production.
А в целом чем вам мешают «костыли древности»? Просто не пользуйтесь «плохими» частями языка.
voidMan
23.11.2015 21:34Ну вообще PHP 7 — большой шаг в этом направлении, с очень достойной совместимостью
defuz
24.11.2015 00:20А смысл, если не будет обратной совместимости, можно просто взять любой хороший существующий язык, с уже созданной архитектурой. Или в PHP есть что-то такое уникальное и близкое к вашему сердцу, и вы хотите это сохранить?
VolCh
25.11.2015 08:14+1Может я ошибаюсь, но среди мэйнстрим языков нет ни одного с такой же легкостью деплоя и прочего администрирования веб-приложений на эталонных реализаций как у PHP. Основной юзкейс PHP в вебе — не апп-сервер, общающийся с веб-сервер, а скрипт, вызываемый веб-сервером. Даже с оберткой php-fpm тот факт, что технически есть fast-cgi сервер, скрывается от разработчика. Для него это всего лишь одноразовый скрипт, который отрабатывает и умирает, что позволяет минимально думать об отдаче ресурсов, даже если бы не было автоматического сборщика мусора.
DrPass
25.11.2015 10:40+1Вы можете взять любое приложение под веб-сервер на любом языке программирования, и схема взаимодействия с веб-сервером будет такая же.
stalkerg
23.11.2015 12:54+5Давайте посмотрим в интернете, какие проекты все-таки используют PHP:
И выбрали его т.к. на тот момент особо не было альтернативы.
Много критики в адрес PHP основано на вещах, которых не было в языке, когда критикующий в последний раз на него смотрел — в начале нулевых.
Увы, проекты которые написаны на PHP образца нулевых, всё ещё встречаются и осложняют жизнь. А так, сейчас конечно к самому PHP претензий гораздо меньше.
Подскажите как обстоят дела в PHP с написанием долго живущих демонов и асинхронных веб приложений?psylosss
23.11.2015 13:01Подскажите как обстоят дела в PHP с написанием долго живущих демонов и асинхронных веб приложений?
Кардинально ничего не поменялось. Либо менять архитектуру (например, sub-pub), либо использовать другие инструменты.
sam002
23.11.2015 13:13+1Воу, воу. Решений полно, например этот проект затисался уже в php-fig, надеюсь в скором времени увидеть фреймворки с коробочной многопоточностью.
stalkerg
23.11.2015 13:17Отличная библиотека кстати, спасибо! Но всё же, проблемы PHP с утечками и т.д. уже исправлены? Где про это можно почитать?
sam002
23.11.2015 18:20С утечками сталкивался года два-три назад последний раз, но и то можно было списать на мою криворукость.
Думаю, что почитать про актуальные и закрытые утечки можно здесь.
psylosss
23.11.2015 13:18Подобные инструменты появились довольно давно. Насколько они стабильны, производительны и надёжны — [для меня] вопрос открытый. Опять-таки, для себя я этот вопрос решил использованием более подходящих инструментов (в моём случае — Go).
FSA
23.11.2015 12:58-2Пробовал разбираться с Java. С удивлением обнаружил, что первые изучаемые конструкции мало чем отличаются от PHP. Правда приходится жёстко расписывать какая переменная что хранит, т.е. кода получается больше.
DrPass
23.11.2015 13:03+16Попробуйте ещё английский поучить. Вы будете приятно удивлены, что там многие слова тоже из PHP заимствованы.
> Правда приходится жёстко расписывать какая переменная что хранит, т.е. кода получается больше.
Если без шуток, то по моему личному опыту строгая типизация — это преимущество, а не недостаток. Лишние байты кода на производительности труда сказываются незаметно, а ряд ошибок/опечаток, которые отлавливаются на этапе компиляции, время и нервы экономят намного больше.FSA
23.11.2015 13:07-1Я к тому, что если нет специфических требований использовать другой язык, то и смысла бросать PHP нет.
DrPass
23.11.2015 13:15+2А что такое «специфические требования»? Вы в большинстве случаев не сможете использовать Java там, где сможете использовать РНР, и не сможете использовать РНР там, где сможете использовать Java. Несмотря на схожесть закорючек. Изучая Java, вы расширяете свой кругозор в сторону серверов приложений, или разработки для мобильных устройств, например, которые вам недоступны как РНР-программисту.
VolCh
24.11.2015 00:22+2Вы в большинстве случаев не сможете использовать Java там, где сможете использовать РНР, и не сможете использовать РНР там, где сможете использовать Java.
В большинстве случаев можно использовать и Java, и PHP, и C#, и С, и C++, и asm, и Brainfuck — возражения против того или иного языка носят экономический и религиозный характер в большинстве случаев.DrPass
24.11.2015 10:38+1Разве? А мне казалось, что возражения против того или иного языка в подавляющем случае определяются возможностями имеющихся библиотек, фреймворков или сред выполнения, имеющихся для этого языка. И что соответствующие «экосистемы», например, для Java, PHP или С практически не пересекаются. Вы, если вам важен сугубо теоретический результат, сможете написать веб-сайт и на ассемблере. Сделать CGI-приложение, которое генерирует контент, подцепить это к веб-серверу, и оно как-то будет работать. Но в реальном проекте ведь такой вариант вы никогда не будете рассматривать просто по технологическим соображениям. Вы скорее всего даже между взаимозаменяемыми технологиями вроде PHP и ASP.NET выбирать не будете (кроме частных случаев, когда проект делается вообще «на голом месте»), а сузите свой круг выбора до того, что лучше впишется в имеющуюся инфраструктуру. Виндовый домен, майкрософтовский софт, внутреннее корпоративное приложение — будет ASP.NET ± MVC. Публикация на хостинге? Вероятно, PHP или что-то аналогичное. И т.д.
VolCh
25.11.2015 08:27Имеющаяся у заказчика инфраструктура — это чисто экономический вопрос приобретения осей. Но, кстати, современные движения в области системного софта, прежде всего в части виртуализации и контейнерации, вполне допускают запуск PHP-приложений в системах с Windows на железе в виртуальным *nix окружением (вроде как Windows Server 2016 вообще нативно поддерживает запуск Linux и FreeBSD контейнеров Docke), равно как запуск .NET-приложение в *nix окружении. Чем дальше — тем меньше приходится думать разработчику о том под какой осью реально будет крутиться приложения, это становится заботой исключительно администраторов.
DrPass
25.11.2015 10:48Так денюжка — это же универсальный измеритель, и вообще любой вопрос при желании можно свести к экономическому :) Например, можно ли на PHP писать под PDP-11? Да можно, конечно. Нанять программиста, чтобы он портировал интерпретатор под PDP-11, и можно. Сугубо экономический вопрос на трудозатраты, верно?
А если без шуток, то это как раз вопрос технологический. Если инструмент предназначен для выполнения каких-либо задач, но его использование дороже или требует квалификации, то это экономика. Если не предназначен, то это технология. РНР не подходит для работы в Windows-домене, просто потому, что там сама исполняемая среда не имеет вменяемых средств интеграции с Windows-приложениями. Поэтому для таких задач вы действительно не будете его рассматривать. А если вдруг будете — это признак непрофессионализма. Вроде «Я знаю только этот инструмент, поэтому я буду плакать, жрать кактусы, срывать сроки, но упорно крутить костыли, пытаясь его сюда впихнуть».
poxu
23.11.2015 13:19+5Смыл бросать php есть когда:
* Нужна выская производительность.
* Нужна поддержка многопоточности.
* Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
* Хочется исключить ошибки, которые можно исключить системой статической типизации.
* Когда достала необходимость ставить доллары перед каждой переменной.sam002
23.11.2015 13:28-5* Нужна выская производительность. -> писать тормозные и тяжелые решения можно на любом ЯП
* Нужна поддержка многопоточности. -> есть много потокобезопасных библиотке
* Хочется исключить ошибки, которые можно исключить системой статической типизации. -> php7poxu
23.11.2015 13:48+4писать тормозные и тяжелые решения можно на любом ЯП
Часто используемая технология ограничивает производительность и если производительность действительно нужна — надо менять технологию.
есть много потокобезопасных библиотек
Нету поддержки concurrency в языке.
php7
Развивается язык. Это не может не радовать. Проверка типов при компиляции или в рантайме произходит?PQR
23.11.2015 15:56+1Компиляции как таковой нет, но есть статические анализаторы, которые вы можете запустить, например, перед коммитом в репозиторий — это и будет аналог проверки типов «при компиляции». В рантайме проверка тоже будет происходить, если указаны интерфейсы и, начиная с PHP 7, скалярные типы.
jrip
23.11.2015 13:43+1>* Когда достала необходимость ставить доллары перед каждой переменной.
Ну это прям мега довод) Или это изза нынешней финансовой ситуации и ипотеки в валюте?))
>Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
Он там есть.
>* Нужна поддержка многопоточности.
Тоже есть.
>* Нужна выская производительность.
Если нужна высокая производительность то тогда не php надо бросать, а учить с++ и писать частично на нем именно те части, которые требуют высокой производительности, java тут будет не полноценным выходом.
>* Хочется исключить ошибки, которые можно исключить системой статической типизации.
выше написали про php 7, но в целом никто не мешает запилить например ассёрты уже сейчас.
poxu
23.11.2015 14:07+1Перед каждой переменной нужно ставить дополнительный символ, которы набирается с шифтом. Это раздражает.
Есть удобный механизм для хранения разделяемых ресурсов в памяти? Чтобы, например, каждый запрос использовал один и тот де коннекшн к БД? Когда я интересовался вопросом, для этого нужно было использовать отдельный сервер. В языке для этого ничего не было.
Есть поддержка многопоточности? Прямо concurrency? Если это так, то язык за последние 2 месяца сделал гигантский прорыв. Можно снипет, как создать 2 потока, которые имеют доступ к разделяемой переменной? Как сделать критическую секцию? Есть ли модификатор volatile?
Если нужна высокая производительность то тогда не php надо бросать, а учить с++ и писать частично на нем именно те части, которые требуют высокой производительности, java тут будет не полноценным выходом.
Всё зависит от требуемой производительности. И наличия легаси кода. С легаси кодом — действительно легче переписывать куски. Если проект новый, то java (дажа java) даст рост производительности в разы.
выше написали про php 7, но в целом никто не мешает запилить например ассёрты уже сейчас.
Закат солнца вручную? Да, приходится иногда делать. Но лучше, когда язык делает за тебя.
jrip
23.11.2015 14:35-2>Закат солнца вручную? Да, приходится иногда делать. Но лучше, когда язык делает за тебя.
Ну да, а вот в той же java многих бесят постоянные и временами ненужны пляски с типами, да и со многим чем другим.
Ага вот, поэтому появляется что-то вроде scala, которая как java, но не совсем. Почему-то никто не плодит всяких «улучшенных пхп»
>Есть удобный механизм для хранения разделяемых ресурсов в памяти?
>Чтобы, например, каждый запрос использовал один и тот де коннекшн к БД?
Это т.е. несколько хттп запросов к пхп и конекшен один? А зачем так? Берем тогда phpDaemon, производительность у него на уровне nodeJS. Если именно ресурсы как данные, то apc есть.
>Есть поддержка многопоточности? Прямо concurrency?
Сыплете терминами всякими, прям как гуманитарий какой. Мы то люди простые, вы задачу опишите, которую хотите решить, там и понятно будет может это пхп или нет. На счет же всяческих указателей компилятору что оптимизировать что нет, тут конечно же нет.
>Если проект новый, то java (дажа java) даст рост производительности в разы.
Ну да, правда есть такой огромный шанс, что когда его на java напишут он уже нафиг никому не нужен будет.
С пхп все несколько веселее, прототип — за месяц на коленке, тут главное опыт иметь и чтот-то вроде архитектуры придумать. Далее можно тупо кусками тяжелые моменты запиливать, например, демонами на с++. На больших данных и тяжелых манипуляциях с ними — с++ джаву сделает только в путь.
DrPass
23.11.2015 14:59+1> Это т.е. несколько хттп запросов к пхп и конекшен один? А зачем так?
Хм. Хороший вопрос. Я вспомнил, как лет семь назад писал к PHP свой экстеншен, только для того, чтобы была возможность обеспечить один разделяемый пул коннектов в рамках всех запросов. Потому что иначе сервер просто ложился под нагрузкой.jrip
23.11.2015 15:14-2Ложился только от коннектов? Странно. Или вы так что-то вроде кеширования намутили?
Если речь идет про то что база не справлялась, то понятно дело, что PHP тут не причем.
Если же про то что application сервер падал, ну т.е. там где PHP крутится — то тут у нас все делается по другому, таких серверов ставится несколько, добавляются по мере необходимости, пока их пара десятков это выгодно, т.к. железо в целом стоит дешевле программистов :)DrPass
23.11.2015 15:55+2Ничего странного. Любой коннект к базе — это значительные накладные расходы на сам коннект плюс на поддержание пользовательской сессии в СУБД. Поэтому если есть возможность их переиспользования, производительность вырастает очень существенно. В моем случае единый пул коннектов вообще убрал в этом узле проблему производительности как класс, без необходимости наращивать мускулы железяке. Это только кажется, что сервер дешевле программиста. Обычно оценивают только стоимость самого сервера, но при этом забывают, что на чашу весов сервера надо положить ещё его установку, конфигурирование и далее эксплуатационное обслуживание, причем тоже живыми людьми с вполне недешевым рабочим временем. Плюс, новый сервер — новая точка отказов.
jrip
23.11.2015 17:08>Ничего странного. Любой коннект к базе — это значительные
>накладные расходы на сам коннект плюс на поддержание пользовательской сессии в СУБД.
Коннект по сравнению со всем остальным это копейки обычно, опять же непонятно что вы такое делали? Да и что за база была? Ну ни разу даже не слышал про проблему с такой стороны. У вас был пучок пхп скриптов запущенных как демоны? Вообще обычно узкое место — это хранение данных, т.е. сколько можем записать прочитать, какой язык это уже дело второе.
> Это только кажется, что сервер дешевле программиста.
Так можно посмотреть на цены, ну и мы же не имеем ввиду джуниоров работающих за еду в роли программиста?
> Обычно оценивают только стоимость самого сервера, но при этом забывают,
> что на чашу весов сервера надо положить ещё его установку,
>конфигурирование и далее эксплуатационное обслуживание,
>причем тоже живыми людьми с вполне недешевым рабочим временем.
Сочувствую, что вам приходится работать с людьми, которые забывают столь важные вещи)
Впрочем я про то, что 10 или 20 серверов разницы по поддержке почти нет, они же типовые будут. Все разворачивается и настраивается почти автоматом, если, конечно, все профессионально делать. Сейчас огромная куча разных программных средств, которые очень сильно облегчают работу. По сути добавление сервера сводится к загрузке образа и запуску установочного скрипта. Для мониторинга также есть куча всяких средств.
>Плюс, новый сервер — новая точка отказов.
Это вы вообще про что?) Ну как бэ банально балансер же можно настроить, чтоб он дальше запрос перекидывал, если какое-то железо сдохло)DrPass
23.11.2015 17:24+2Со «всем остальным» — это какое остальное вы имеете в виду? Найти запись по индексу в таблице? Нет, коннект обычно будет осуществляться дольше. Сложный запрос с кучей условий/объединений, и потом обновление по нему? Ну да, коннект обычно будет осуществляться быстрее. И то, и другое — достаточно типовые задачи. Поэтому что тут смущает, непонятно. Конкретно эта система — это был автомат для платежной системы, который должен был быстро молотить выборки по состоянию счетов для сети собственных терминалов и гейтов банков.
> Так можно посмотреть на цены, ну и мы же не имеем ввиду джуниоров работающих за еду в роли программиста?
_Любого программиста_ Сколько стоит, скажем, месяц работы хорошего программиста? Ну четыре-пять тысяч долларов в столице. Если он потратит пару недель своей работы на то, чтобы сэкономить на установку целого сервера, это окупится за полгода.
> Впрочем я про то, что 10 или 20 серверов разницы по поддержке почти нет, они же типовые будут.
Т.е. в тех задачах, где можно было просто оптимизировать код, вы предлагаете не просто забить на оптимизацию, а поставить уже даже не дополнительный сервер, а целую ферму. И развернуть инфраструктуру для обслуживания этого добра. Мне кажется, экономическую часть вашего диплома вы в своё время завалили :)
> Это вы вообще про что?) Ну как бэ банально балансер же можно настроить, чтоб он дальше запрос
> перекидывал, если какое-то железо сдохло)
Ну да, только это будет для следующего запроса, а не тех, которые были на железке в момент сбоя. И то, когда железо перестанет откликаться. И в том сферическом случае, когда у вас такой сервис, который всё-таки предполагает целую ферму серверов в кластере.jrip
23.11.2015 18:37-1>Если он потратит пару недель своей работы на то,
>чтобы сэкономить на установку целого сервера, это окупится за полгода.
Откуда такие цифры как пара недель и целого сервера? Обычно речь идет о процентах, ну мыж не говорим о системе которую писали джуниоры и ни разу не проверяли под нагрузками?
>Т.е. в тех задачах, где можно было просто оптимизировать код, вы предлагаете не просто забить
>на оптимизацию, а поставить уже даже не дополнительный сервер, а целую ферму.
Нет я лишь говорю что вы асбоютно не правы, и что в нормальном проекте для еще десятка серверов не придется заводить в два раза больше админов.
>Мне кажется, экономическую часть вашего диплома вы в своё время завалили :)
А вы похоже сдали с отличием?) Похвастайтесь в каком вузе так пофиг на дипломы)
Впрочем если без стеба тут хватит школьной математики:
Мой опыт показывает, что сервис на java дольше разрабатывается, раза в два, прогеры в целом стоят больше, а в результате выйгрыш на серверах раза в два в лучшем случае. Если говорить о проекте, который изначально заведомо успешный, то согласен, php я бы для него не выбрал, однако обычно рулит скорость старта. Ну и также покупать серваки смысл есть не всегда, есть аренда, а там окупаемость совсем другая. Возможно у вас другой опыт, но без цифр и предметной области это будет всего лишь тупой спор.
>Ну да, только это будет для следующего запроса, а не тех, которые были на железке в момент сбоя.
Чтото я туплю, но разве повысится статистически шанс потерять запрос при увеличении количества серверов и таком же количестве запросов? Учитывая что время обработки сильно отличаться не будет.DrPass
23.11.2015 19:10> Откуда такие цифры как пара недель и целого сервера? Обычно речь идет о процентах
Цифры условные. Я просто обозначил порядок. Мы ведь говорили об оптимизации, которая позволит обойтись без кластера.
> Нет я лишь говорю что вы асбоютно не правы, и что в нормальном проекте
> для еще десятка серверов не придется заводить в два раза больше админов.
Вы просто забыли сначала упомянуть, что «нормальный проект» в вашем понимании — это когда трудится большая ферма с балансировщиком нагрузки, и плюс десяток/минус десяток серверов, это не проблема. Т.е. остальные 99.99% проектов, которые прекрасно помещаются на одном хосте, не нормальные. Но я всё-таки имею в виду большинство, а не достаточно редкий частный случай.
> Мой опыт показывает, что сервис на java дольше разрабатывается, раза в два, прогеры в целом стоят
> больше, а в результате выйгрыш на серверах раза в два в лучшем случае.
Мы вообще про Java сейчас не говорили, а только про РНР :) По-всякому бывает на самом деле. И в любом случае, эти две платформы крайне редко конкурируют в рамках одного или даже одинаковых проектов.
> Ну и также покупать серваки смысл есть не всегда, есть аренда, а там окупаемость совсем другая.
Математика тут простая. Любой облачный провайдер будет нести те же затраты на сервер, что и вы, плюс он ещё платит свои налоги и хочет поиметь прибыль. Экономия для клиентов достигается за счет того, что облачный провайдер разделяет свои ресурсы между многими клиентами, каждый из которых «в среднем» потребляет чуть-чуть от арендуемой мощности. Если же ваш проект употребляет сервер «под завязку», вам всегда будет дешевле иметь собственный сервер, чем арендовать.
> Чтото я туплю, но разве повысится статистически шанс потерять запрос при увеличении количества
> серверов и таком же количестве запросов?
Нет, статистически не повысится. Речь была о том, что балансер — не панацея от проблем, и не избавит клиентов от потери транзакции.
poxu
23.11.2015 18:36+1Коннект по сравнению со всем остальным это копейки обычно, опять же непонятно что вы такое делали?
Установка соединения это вечность. Если по запросу надо только вернуть небольшой кусок данных, а это характерно для REST API — большая часть времени будет затрачена именно на установку соединения.jrip
23.11.2015 18:39Как бы отдавать напрямую данные из базы довольно фиговая ситуация, однако в среднем большая часть должна быть покрыта кешами.
poxu
23.11.2015 18:51Обработка данных это тоже мгновения. А запросы к бд кешируются, но надо сначала установить коннект.
kazmiruk
23.11.2015 20:53+2Именно такие комментарии и делают плохую репутацию пхп разработчикам. Вам стоит почитать Тенебаума прежде чем что-то утверждать. И даю подсказку — чтобы взять данные из кеша к нему тоже стоит подключиться, т.е. установить коннект.
VolCh
25.11.2015 08:35Всё зависит от времени формирования этого куска. Одно дело выбор одной строки по ключу из уникального индекса, совсем другое сложный агрегирующий запрос, почти не использующий индексы.
DrPass
25.11.2015 10:57Хм. Вообще-то если вы видите «сложный агрегирующий запрос, почти не использующий индексы», его обычно нужно брать и переписывать так, чтобы он был менее сложный, и использовал индексы, а не возражать: «Нууу, коннекшен иногда выполняется быстрее, чем выборка» :)
Fedot
25.11.2015 23:48Не могу не накинуть чуть справедливости по поводу постоянных коннектов php.net/manual/en/features.persistent-connections.php
Они есть и очень очень давно.DrPass
26.11.2015 02:08А это не совсем то, что требовалось. Нужен был именно пул подключений, с возможностью наращивания числа открытых коннектов при росте нагрузки на узел, и с их высвобождением, и т.д.
Fesor
26.11.2015 11:35+1Ну как бы, это можно реализовать поверх pconnect. Да и в чем смысл организовывать пул своими силами, если у нас и так есть ограничения, сколько одновременно запросов может обрабатываться (по количеству воркеров). А держать постоянно открытыми 3-4 соединения в принципе не затратно.
Все же другие варианты где это имеет смысл (ну или я вижу в этом смысл) только в контексте демонов. И даже в этом случае «экстеншены» свои писать не надо.DrPass
26.11.2015 12:26В рамках скрипта PHP ведь не организуешь — он отработал и ушёл. Разделяемых ресурсов как таковых там нет, чтобы как-то организованно управлять пулом. Плюс, была необходимость вешать запросы в очередь при заполнении пула, т.к. количество лицензий на подключение к базе данных было лимитировано «сверху». Я уже всех деталей не вспомню, всё-таки столько времени прошло, но помню, что проблему со всех сторон мучили, прежде чем решиться на разработку экстеншена. И pconnect, и конфигурированием апача, и т.д.
Fesor
26.11.2015 15:50В рамках скрипта PHP ведь не организуешь — он отработал и ушёл.
в этом суть pconnect, соединение с базой кешируется и реюзается в рамках воркера. Если вы не закрыли соединение вы сможете его реюзать потом.
Fesor
26.11.2015 16:02Плюс, была необходимость вешать запросы в очередь при заполнении пула
опять же, у вас ограниченное количество воркеров (пых синхронный по дефолту), у каждого свое соединение, не надо никаких очередей.
В целом я думаю что разработка экстеншена для управление соединением с базой это… мягко скажем дикая крайность. Потому меня так и заинтересовало выяснить причины — любопытно какие задачи это решало.
poxu
23.11.2015 16:19+4Ага вот, поэтому появляется что-то вроде scala, которая как java, но не совсем.
Которая как джава, но не совсем это groovy. scala это совсем не как джава, но исполняемая в джава машине.
Почему-то никто не плодит всяких «улучшенных пхп»
В основном потому, что это технически сложно. Сделать новый язык, который будет исполняться в джава манине —
задача отностительно простая. Автоматом этот язык будет иметь доступ к джава коду.
Поэтому таких языков много.
Ну и есть ещё одна причина. Когда java программист уставал от джавы у него не было альтернатив. Так и
появились эти языки. У программиста на php альтернатив море — начиная от ruby и кончая Go. Для перехода с
php ему не надо ничего, кроме желания.
Это т.е. несколько хттп запросов к пхп и конекшен один? А зачем так?
Чтобы не поднимать новый коннекшн на каждый запрос.
Берем тогда phpDaemon, производительность у него на уровне nodeJS. Если именно ресурсы как данные, то apc есть.
Вот я и говорю, удобно это не сделаешь. Только приблудами всякими.
Сыплете терминами всякими, прям как гуманитарий какой.
Эти термины знает каждый программист. Кроме тех, конечно, которые используют языки не поддерживающие многопоточность.
Чтобы раскрыть что такое многопоточность и зачем она нужна нужно написать целую книгу и не одну.
php многопоточность, увы не поддреживает.
На счет же всяческих указателей компилятору что оптимизировать что нет, тут конечно же нет.
volatile нужен не для оптимизации, а чтобы прорамма вообще работала.
Ну да, правда есть такой огромный шанс, что когда его на java напишут он уже нафиг никому не нужен будет.
Всё, что делается на php быстро на джаве делается примерно с той же скоростью. То, что на php делать долго, на джаве, как правило делается быстрее.
С пхп все несколько веселее, прототип — за месяц на коленке, тут главное опыт иметь и чтот-то вроде архитектуры придумать. Далее можно тупо кусками тяжелые моменты запиливать, например, демонами на с++.
На джаве примерно так же, только можно не запиливать демоны.
На больших данных и тяжелых манипуляциях с ними — с++ джаву сделает только в путь.
Большие данные это зачастую Hadoop и Spark.
jrip
23.11.2015 14:38+1>Перед каждой переменной нужно ставить дополнительный символ, которы набирается с шифтом. Это раздражает.
Ну детский сад, ну IDE уже наконец настройте чтобы он за вас это делал. Вы еще скажите что по пять мегабайт кода в день пишите, что от лишнего нажатия на шифт устаете.NeonXP
23.11.2015 17:22Шутки шутками, а я как-то увлекшись процессом «пробил» мизинцем на ноуте клавиатуру как раз в районе левого шифта. Точнее сломал крепления, поддерживающие плату с клавишами в том районе. Так что, обилие нажатий на шифт в процессе программирования на РНР действительно вредно.
шучу
VolCh
25.11.2015 08:31Перед каждой переменной нужно ставить дополнительный символ, которы набирается с шифтом. Это раздражает.
Если этот аргумент серьезно рассматривается, то PHP умрёт (или, хотя бы, опустится до доли Perl-а — когда-то своего основного конкурента) очень не скоро :) Плюс в явном разделении пространств имён переменных и других сущностей есть свои плюсы. Как минимум меньше ограничений при выборе имён.
webkumo
23.11.2015 14:45+1«Если нужна высокая производительность то тогда не php надо бросать, а учить с++ и писать частично на нем именно те части, которые требуют высокой производительности, java тут будет не полноценным выходом.»
Просто интереса ради почитайте про HFT, а, заодно, на чём там пишут. Не ручаюсь за полный список языков, но java там точно участвует и не на последних ролях.
">Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
Он там есть."
Вот прям не велосипеды и не Mongo/etc, а прямо сервер приложений/ядро оного на языке, способные обслуживать множество запросов? И скрипт не грузится перед каждым выполнением заново? Если так — мои поздравления, язык наконец-то начинает подбираться к промышленным/«энтерпрайз»-языкам.jrip
23.11.2015 14:57>Просто интереса ради почитайте про HFT
Ок спасибо, просто в некоторых задачах на практике c++ показал себя сильно намного лучше, возможно я что-то делал не так.
>И скрипт не грузится перед каждым выполнением заново?
Да это давно уже нет, nginx воркеры все такое, а есть еще hhvm
>Вот прям не велосипеды и не Mongo/etc, а прямо сервер приложений/ядро оного на языке,
>способные обслуживать множество запросов?
Можно и так сделать, только смысла особого не имеет, реализации общей памяти да, могут показаться надстройкой, однако для решения задач вполне себе хватает и пользоваться в целом удобно.webkumo
23.11.2015 16:23+1Большинство сравнений, где с/с++ выигрывают больше нескольких процентов — неудачная реализация на Java. Есть случаи, когда Java действительно плохо подходит, но их не так уж и много.
Пока сам не работал с джавой — даже не задавался мыслями о пользе разделяемых данных… правда я достаточно быстро ушел на Java (о чём не жалею) и вот тут уже и увидел пользу.
Flammar
23.11.2015 15:30+1Если смотреть совсем узко, то Java тупо ест на порядок меньше ресурсов на отрисовку такой же страницы. Плюс Java — это язык, на котором написан весь сервер, а не только модуль для Apache, хотя насколько это важное преимущество — ещё вопрос.
Там, где есть LAMP, смысла бросать PHP точно нет. Вообще смысл «бросать» что-то бывает довольно редко.FSA
23.11.2015 18:14PHP — это не только модуль для Apache. Можно и без Apache вполне обойтись используя Nginx для отдачи статики и проксирования запросов к PHP-FPM. На счёт ресурсов ничего не могу сказать. Измерений не делал. Но при небольшой нагрузке связка работает и на виртуалке с 512Мб помяти.
VolCh
25.11.2015 08:36+1Скажем так, сейчас для использования Apache мне нужны веские доводы.
FSA
25.11.2015 08:38Я пока только один довод слышал — требуется исключительно поддержка .htaccess. Если бы к nginx прикрутили заменитель, но большинство бы от Apache совсем отказалось.
VolCh
25.11.2015 08:52Есть ещё один довод — имеющаяся инфраструктура уже работает на Apache и параллельную никто разворачивать не собирается. Тогда приходится вспоминать как пишется .htaccess :)
sam002
23.11.2015 18:26+5Про вас уже писали, что вы застряли в прошлом десятилетии. Какой модуль apache?!
VolCh
25.11.2015 08:51Можно поподробнее про «на порядок»? И что считается «ресурсами на отрисовку» — память, выделяемая при запуске сервера до прихода первого запроса туда входит или нет? Как минимум, потребляемая память состоит из постоянных ресурсов на поднятие сервера и ресурсов потребляемых на один запрос (а после него освобождаемых).
ov7a
23.11.2015 13:00+7Ну да, а ABAP использует такой гигант как SAP.
Facebook использует не чистый php, и разрабатывают Hack.
Есть такое понятие, как legacy. Возможно компании до сих пор используют php, просто потому, что у них нет выбора: переписывать будет очень дорого.
P.S. Какой удобный пост, чтобы словить минусов в карму
AlexLeonov
23.11.2015 13:02+3Ну так пусть ноют. И валят куда подальше. У остающихся будет выше зарплата )))
А если серьезно — то у PHP на ближайшие лет пять альтернативы нет. И вряд ли появится. Особенно это очевидно стало с выходом PHP 7.sam002
23.11.2015 13:19-5Вангую угрозу со стороны JS после реализации классов и прочего ООП. Над nodeJS работает очень много крутых специалистов с мощным матаном, сам не пользую, но наработки типа libUV очень впечатляют.
Конечно не пять лет, но не будем зарекаться, впрочем.AlexLeonov
23.11.2015 13:41+2Я про пять лет потому, что это как раз средний срок жизни технологий и экосистем. PHP уже третий такой срок переживает (условно — «старый», «пятерка» и теперь «семерка») и ничего — делается только лучше.
Не вижу я угрозы со стороны JS, вот что хотите делайте. Не в состоянии себе среднестатистический джуниор быстро и решительно сломать себе мозг, чтобы хорошо писать на JS. На PHP же за год активной работы любое криворучье при наличии вменяемого тьютора доводит себя до промышленных стандартов.
jrip
23.11.2015 13:46На nodeJS большой проект писать и поддерживать дороже, там не только с ООП проблемы, их там еще оч много, пока все допилят и привыкнут, те же лет пять точно пройдут а скорее намного больше.
sam002
23.11.2015 13:03Критика нужна, даже неконструктивная! Вернитесь на те же 10 лет назад и всспомните какой поток негатива изливался на Java, всё ещё живо предубеждение что Java тормозной, хотя быстродействие кода в 99% зависит от прокладки между ТЗ и кодом. Критикуется то что развивается, имхо.
Уверен что через 10 лет не меньше критики будет в отношении JS.
Apathetic
23.11.2015 13:18+1В отношении JS и сейчас немало критики, но разница в том, что JS безальтернативен для фронтенда (если не учитывать языки, компилирующиеся в JS, типа TS или CS).
sam002
23.11.2015 13:21+1На фоне критики php, критика JS — это ворчание из угла. То ли ещё будет когда начнётся массовое использование стека с nodejs…
kahi4
23.11.2015 13:42+22Как front-end разработчик заявляю: у js адское количество проблем. Не буду говорить за всех, но у меня сложилось примерно такое ощущение:
php-разработчики любят php
python-разработчики обожают python
ruby-разработчики влюблены в ruby
js-разработчики на одном месте вертели js (повторюсь, чисто мое ИМХО)
Посмотрите сами — каждый день появляется по десятку библиотек и фреймворков, в которых авторы пытаются закрыть несовершенство языка. Раз в год появляются крупные и громкие релизы, которые переворачивают всю разработку с ног на голову (jQuery, потом Backbone, потом Angular и Ember, вот недавно React, ждем, что же будет дальше). Раз в три-четыре года появляются надстройки типа CoffeScripts, Dart, TypeScript, EJX, которые теперь еще начали перемешиваться между собой с адской силой. Теперь еще и релизы ES каждый год. Браузеры еще в ES6 толком не могут (нативно), а на подходе ES7 (ES2016 вроде, теперь по годам называют), который вдобавок ужасно вкусный.
Ну и все это заправлено соусом из пугающих новичков странных правил вывода типа, кучи мест с граблями, всплытия переменных и рвущим пришедшим из других языков мозг прототипным ООП.
Но, как будто бы этого мало — чтобы быть топовым разработчиком, необходимо знать это все сразу. Кучу самых новых и адски старых библиотек, технологий, сборщиков. И мало того, чтобы просто знать — нужно постоянно отслеживать новейшие подходы. Облизываться, вытирать слюнки и продолжать пилить проект на легаси, потому что если начнешь переделывать — не успеешь, обязательно выйдет что-то еще новее, еще круче. И вот, ты мегакрутой разработчик, используешь самые передовые технологии, сходил в отпуск на месяц, вернулся — уже устарел и бомж в свой стартап не позовет.
Так что в отношении JS очень много критики. Просто она какая-то не такая отъявленная, покуда выхода то нет… С другой стороны, не припомню ни одного другого столь стремительно развивающегося и обрастающего библиотеками языка.
Что касается PHP — язык как язык. Со своими недостатками и преимуществами. Мне сильно подпортило впечатление о нем, что у него очень низкий порог входа, в следствие чего, многие начинают свою карьеру разработчиками именно с него, а в итоге приходится работать с кучей Legacy настолько отвратительного качества, что появляются мысли на подобие «ужасный язык», хотя он лишь инструмент и все зависит от того, как его использовать.sam002
23.11.2015 18:15Прочитал)) Это я про js циклюсь под впечатлением от копания под капотом nodejs.
В целом достойные замечания о бешенной динамике, буду теперь более сочувственно относиться к фронтендщикам.
А про принятие новых стандартов даже ещё не слышал((
poxu
23.11.2015 13:12+3Есть язык программирования С на котором написано на порядки больше, чем на php. Никто, однако, (кроме разве что Линуса Торвальдса) не спорит, что у него есть объективные недостатки.
В случае с php ситуация похожа, только хуже. Недостатков куча (чего стоит только одна необходимость ставить знак доллара перед каждой переменной), а вот из достоинств только низкий порог входа и повсеместная распространённость на хостингах. Мало того, есть вещи, которые php просто не может (например concurrency).
Так что программистам на этом языке можно только поапплодировать. Используя очень ограниченный инструмент они умудряются создавать отличные высококачественные продукты.
Это делает честь программистам, но ничего не меняет в том, чем на данный момент является php. Правда я, как и многие другие, ещё помню времена, когда не было и того. php постепенно развивается и возможно когда-нибудь он изменится настолько радикально, что критиковать его станет сложно. Но это момент ещё не наступил.DoctorChaos
23.11.2015 13:36+11Да, знак доллара перед именем переменной это, несомненно, ужасный недостаток. Главный, я бы сказал. Надеюсь, в РНР8 они исправят эту проблему, о которую спотыкается столько светлых идей, которые нельзя воплотить в жизнь из-за проклятого доллара.
Кстати, именно слишком низкий порог входа я считаю недостатком. Даже странно, что вы записали это в достоинства :)shoomyst
23.11.2015 14:03+18Вчера только новость проскакивала, что госдума призывает отказаться от php из-за необходимости использования знака доллара
poxu
23.11.2015 14:09-1Перед каждой переменной нужно набрать символ, для набора которого надо зажать шифт. Кто-то будет спорить с тем, что это неудобно и глупо? Кто-то скажет, что это даёт хоть какие-то преимущества?
DoctorChaos
23.11.2015 14:19+5Упаси боже с вами спорить. Страшно представить, что с вами будет, когда вы узнаете, как объявляются переменные в Java :)
poxu
23.11.2015 14:26+1Вы про то, что нужно указывать тип переменной? Да, есть такой косяк. Во многих языках его потепенно устраняют автоматическим выводом типа.
Но, в отличие от доллара в php, тип в java надо указать только при объявлении, а не при каждом использовании. И, в отличие от доллара в php, польза от статической типизации огромна и неоценима.
Flammar
24.11.2015 10:41Обычно в Java тип переменной автоматически проставляется с помощью IDE;-). Это если, конечно, не хочется специально поупражняться и понабивать шишки в блокноте…
AlexLeonov
23.11.2015 13:45+3С чего хоть вы взяли, что в PHP низкий порог входа? Это настолько распространенный, насколько же и неверный миф.
PHP — сложный язык. Реально сложный. И хорошо писать на нем не легче, чем на Java, например.
P.S. Посмотрел в мониторинге, как себя чувствует мой демон, написанный на PHP, работающий с Websokets (чат между клиентами и менеджерами). Чувствует нормально. Аптайм — две недели. Что я делаю не так?kahi4
23.11.2015 14:07+1Для того, чтобы просто взять и начать писать — на php достаточно низкий порог входа. Ниже, чем у большинства других языков. Причем, этого низкого уровня достаточно, чтобы клепать сайты-визитки. Однако многие, почему-то, считают, что этого им достаточно и пытаются начинать пилить большие проекты. Как аналогия — научиться прятать формочки при клике на крестик в js можно за 5 секунд гугления: $('#button').click('form').slideUp(). Вот только между подобной конструкцией и строчкой «я знаю js» — пропасть в несколько лет. Так же и в php — между страничкой с инлайновыми SQL запросами до «я знаю php» — большая разница. Вот только часто люди, находящиеся на первом этапе, идут в разработчики, которые потом разрастаются, становятся неподдерживаемыми и их даже страшно открывать.
P.S. И, в конце концов, смотря с чем сравнивать. На PHP гораздо проще научиться писать, чем на том же C, C++, D или ASM, Haskell, F# и erlang. Про verilog, vhdl и lustre (на нем кто-то пишет?) промолчим, по уровню вхождения до ним всем далеко.kahi4
23.11.2015 14:13+1$('#button').click(() => { $('form').slideUp(); });
Конечно же, что это со мной.
Stalker_RED
23.11.2015 18:27Тогда уж
$('#button').on('click', (e)=>{
$('#form').slideUp();
e.preventDefault();
});
.on('click', ...) позволит вешать больше одного обработчика на кнопку, а preventDefault на случай, если вы всё-же не собираетесь отправить форму этой кнопкой.kahi4
23.11.2015 18:58+1Я про начинающих разработчиков. Какие там preventDefault? Только return false; только хардкор. Да и какие arrow functions? Кому нужны эти babel, сборщики?
Ну и тогда уж $('form').on('submit'...), чтобы максимально корректным. Ну и если это единственная вставка js, то vanillaJS наше все. Но это отдельный разговор.
poxu
23.11.2015 14:16С чего хоть вы взяли, что в PHP низкий порог входа?
Очень много простых задач, для решения которых язык почти не надо знать. Типа добавить текущую дату в какую-нибудь талицу. И за это уже заплатят деньги.
PHP — сложный язык. Реально сложный.
Да, это так. И это ужасно. Сложность — для языка программирования не достоинство.
И хорошо писать на нем не легче, чем на Java, например.
Да, хорошо писать на Java значительно легче. Хотя экосистема Php в последнее время во многом копирует экосистему java.
DoctorChaos
23.11.2015 13:50+3из достоинств только низкий порог входа и повсеместная распространённость на хостингах
Откровенная неправда. Либо вы решили вбросить, либо не знаете о чем говорите, либо просто некомпетентны :)poxu
23.11.2015 14:12Что неправда? То, что php повсеместно распространён? Или про низкий порог входа?
DoctorChaos
23.11.2015 14:14+2То, что это единственные достоинства РНР, не тупите :)
poxu
23.11.2015 14:18Какие ещё у php есть достоинства по сравнению с другими языками?
SamDark
23.11.2015 15:12+1Share nothing.
poxu
23.11.2015 16:06+1Реализуемо в любом языке.
SamDark
23.11.2015 18:16+1Да, только в случае PHP когда внезапно прилетает проект «ааа!!! трафик!!!» можно что-то сделать потому как share-nothing по умолчанию, а вот в случае, например, Java, чаще всего уже поздно.
poxu
23.11.2015 18:30Если проект пишут неопытные разработчики, то наверное так и есть. Но такие с трафиком в любом случае будут иметь сложности. А если разработчики понимают, что делают, то у джавы есть огромное количество проверенных методов распараллеливания кода. По принципу делай раз, делай два, делай три.
SamDark
23.11.2015 19:04+1В том-то и дело, что внезапно выстреливший прототип на PHP (а прототипы не стоит делать за 100500$ сразу потому что они чаще всего не выстреливают) можно заставить справиться с нагрузкой пока реализуется чистовая версия проекта. На Java во-первых по финансам у нас получится 2 прототипа вместо 20 на PHP, а во-вторых по скорости эти прототипы будут выдаваться раз в несколько медленней.
poxu
23.11.2015 19:12Ну собственно как я и говорил. Квалификация программистов на php ниже, стоят они дешевле, прототип собирают дешевле. Быстрее, чем у джава программистов с нормальной квалификацией, правда, не получится. Но стоить будет действительно меньше. В том числе поэтому php и пользуется такой популярностью.
А вот чтобы прототип кто-то хоть раз переписывал начисто я не видел вообще никогда :(.VolCh
24.11.2015 00:32+2Быстрее, чем у джава программистов с нормальной квалификацией, правда, не получится.
Почему не получится? Что есть в джава, что ускоряет разработку? Чего нет в пхп?poxu
24.11.2015 12:53Да ничего особо нет. Поэтому скорость изготовления простых проектов примерно одинаковая. Поэтому на php не получится быстрее, чем на java.
sam002
23.11.2015 18:10+1Большой выбор серьёзных и развивающихся фреймворков.
poxu
23.11.2015 18:25+1Большой выбор серьёзных и развивающихся фреймворков есть в java, ruby, python, go, c#, scala. Пара веб фреймворков есть даже для С++. Это не отличает php от всего остального.
sam002
23.11.2015 18:34+1Так мы киллер-фичи ищем или просто плюсы перечисляем?
Ну и имелось ввиду что фреймворки ориентированы на вэб и их много. Кроме RoR и django ничего сравнимого с symphony, yii, laravel etc не вспоминается.
Пара же фреймворков на плюсах пригодны для эмбедед только. А про java в вэб отписывался SamDarkandrewnester
23.11.2015 18:49Вы правы, насчёт того, что кроме RoR и Django нет ничего особо известного, не считая вариантов с Flask, Bottle, Sinatra
но есть такой нюанс — данные фреймворки так или иначе повлияли на имеющиеся в PHP.
та же ситуация и с библиотеками, например, behat, на который повлиял cucumber.
но я сходу не вспомню фреймворков/библиотек, на которые повлияли Symfony, Laravel, Yii.
да, PHP развивается, я как PHP-программист очень этому рад.
но иногда создаётся впечатление, что PHP играет «в догонялки» с другими языками.
а я бы искренне хотел, чтобы на PHP-инструменты равнялись, при создании инструментов в других языкахSamDark
23.11.2015 19:07+2Какая разница, кто был первый?
Yii повлиял на Symfony, Laravel и совсем немного на RoR. Они, в свою очередь, повлияли на Yii. Мы не в вакууме живём и у разработчиков фреймворков не священная война, а обмен опытом.
Metus
24.11.2015 00:12Разница есть в том, что тот кто первый, первый и находит недочёты и исправляет их.
В тех же рельсах уже давно как отказались от настроек массового присваивания для моделей и обосновали почему — я с ними полностью согласен. А в Eloquent до сих пор protected $fillable и меня это, как PHP-разработчика, немного угнетает — чувствуется именно отставание.
Не надо, конечно же, демонизировать PHP — вполне себе неплохой развивающийся язык. Но надо всё же признать, что ряд вещей в том же python с ruby и, соответственно, фреймворках, сделаны намного удобнее и яляются более зрелыми именно по причине первости.SamDark
24.11.2015 04:30+3Как-бы нет. Видит и исправляет недочёты второй, если этот второй не тупо копирует, а понимает, что делает. Первый уже завязался на ошибки. Надо обратную совместимость сохранить и так такое.
Конечно, если сравнивать фреймворк с десятилетней историей, стабильными версиями и всем таким с чем-то новым-трендовым, но чему пара лет и версии выплёвываются без обратной совместимости как пирожки, то да. Тут очевидна зрелость и не зрелость. Но в общем случае нет…
Мы в Yii ещё в 2010 переделали умолчания для массового присвоения несмотря на то, как делали в рельсах. Рельсы с GitHub и Хомяковым прилично на этом погорели через несколько лет. Тейлор в Laravel тоже много всего поправил при заимствовании (из Yii 1.1 много штук было ещё в Laravel 3), хотя ему тяжелее. Он фактически в одиночку пилил до недавнего времени фреймворк и, к тому же, ему постоянно надо думать, как с фреймворка получить денег потому как это его основное занятие. Это несколько смещает приоритеты и отвлекает.
Что-то в RoR и Django лучше, но что-то хуже.Metus
24.11.2015 09:34Для того, чтобы не тупо копировать, а понимать, нужно иметь длительный опыт использования копируемого, чтобы отследить все тонкие ситуации.
VolCh
24.11.2015 00:33+1но я сходу не вспомню фреймворков/библиотек, на которые повлияли Symfony
Джанга )
poxu
23.11.2015 18:49Я стараюсь перечислить плюсы, которые отличают php от других решений. Большое количество хороших фреймворков к таковым не принадлежит ибо характерно не только для php.
Для java есть play framework, есть Spring который на первый взгляд ну очень поход на laravel, только чутка поудобнее, для scala есть play framework2. Для go названий не помню, но там тоже есть.
Что есть на php, чего нет на других языках это Wordpress :).
Судя по тому, что пишет SamDark он немного отпустил руку с пульса. :)SamDark
23.11.2015 19:10Да, я под веб давно ничего на Java не делал. Последний раз это были Spring и Wicket. Ну и, конечно, Hibernate и ещё туча всякой тяжёлой дряни. Сейчас Java использую для Android. Очень приятно.
ShadowsMind
23.11.2015 22:32Сейчас у Java с Веб все огонь. Тот же Spring Boot позволит в пару телодвижений сделать апликуху с rest, CRUD любой бд без единого запроса(привет Spring Data), кэши и сессии в каком-нибудь Redis, сечьюрность, какой-нибудь модный-молодежный template engine в духе handlebars и прочие прекрасности. Еще парой телодвижений прикручиваешь Spring Loaded или JRebel(а может XRebel, не в курсе их линейки продуктов, не юзал), чтобы не страдать при разработке от «изменил, сбилдил, задеплоил, посмотрел...».
Те кто говорят, что разработка на Java в n раз медленнее X скриптового языка, просто видимо не трогали Java с тех пор(или вообще не трогали и судят с позиции диванного теоретика), как все умные люди поняли, что JavaEE это вообще не комильфо.
В последнее время еще очень понравился Play2, там все так же удобно только «нативненько» со Scala и очень многое доступно «из коробки», плюс очень большой упор на асинхронность.
Ко всему прочему, не нужны никакие XML не для сборки, не для конфигов(и Spring и Play поддерживают «нормальные» конфиги; билдить и подтягивать зависимости в Gradle/Sbt весьма удобно). Пишешь код на том на чем больше «штырит» под JVM и радуешься.
sam002
23.11.2015 18:43Ладно, это всё выше — болтология. Неплохо сформулирована проблема в статье: дискредитация профессиональная и в оплате из-за предубеждений к конкретному стеку технологий.
poxu
23.11.2015 18:58Дискриминация профессиональная — потому, что подавляющее большинство программистов на php имеют низкую квалификацию. Дискриминация по оплате — потому, что большиство задач стоящих перед программистами на php не требуют высокой квалификации для решения.
Высококвалифицированных программистов никто не будет упрекать в том, что они используют php, недостатки которого им самим хорошо известны.sam002
24.11.2015 00:11Вооот, яркий пример — ваше же высказывание. Большинство программистов на любом ЯП имеют квалификацию ниже среднего, ибо градация так сделана, чтобы на 5 мидл один сеньёр приходился, условно. Я знаяю мало плохих программистов, пишущих на php, гораздо больше скрипт-кидди от python и js. А, ещё «плюсисты» полторы лабы скатавшие в универе часто встречаются. Самый плохой вариант php-быдлокодеров — это мамонты, которым ничего кроме легаси десятилетней давности не дававали. Были и на хабре статьи, затрагивающие актуализацию стека, и на тостере трогательные (в хорошем смысле) вопросы встречаются про то как бы вырваться из прошлого.
Упрекают за php, инстенктивно, поддаваясь стадному чувству. Совсем свежий анектод: «А зачем вам phalcon, вот у нас круто из фронта запросы строить!» (хз что за стек они используют).
Adelf
23.11.2015 19:37Какой выбор фреймворков в C#, например? Там есть ASP.NET и все… по большому счету
jrip
23.11.2015 13:57>Есть язык программирования С на котором написано на порядки больше, чем на php.
>Никто, однако, (кроме разве что Линуса Торвальдса) не спорит, что у него есть объективные недостатки.
Фигня в том, что PHP прост, а вот изучить нормально С «обсирателям» уже не получается, поэтому гавнакод на С кажется им адски крутой магией.
.
jrip
23.11.2015 13:34+4>Тех, кто учит PHP, надо изолировать от общества
Раз так ненавидят, значит боятся! правильным путем двигаемся!
Antelle
23.11.2015 14:02Я думаю, вся ненависть к PHP из-за вордпресса, друпала (etc...), специалистов по ним за 20 тыр и студий с рекламой на заборе. Вобщем так сложилось: какой спрос, такое и предложение. Был бы это, допустим, python — такое отношение было бы и к нему. Как-то так.
Metus
23.11.2015 14:32+1Главный недостаток PHP, по-моему, это даже не знаки доллара перед переменными и не согласованные сигнатуры стандартных функций, а тот факт, что многие вещи задаются настройками самого интерпретатора, подключаемыми к нему расширениями и т.д.
Ввиду чего использование того же composer несколько ограничено. Раньше, видимо, поэтому и сделали общесистемный PEAR по аналогии с расширениями.
В каком ещё интерпретируемом языке такое есть?SamDark
23.11.2015 15:13В Ruby?
Metus
23.11.2015 15:50В Ruby нет разницы между библиотекой и расширением — это всё gem-ы.
По-умолчанию они ставятся в систему, с появлением bundler-а куда хочется — чаще всего в папку с проектом, т.е. не нужны права суперпользователя.
Но и в первом случае нет никаких системных ruby.ini файлов, которые задают как должны работать проекты, использующие его.
stychos
26.11.2015 22:29+1Но разве ультрамодная ныне концепция докеров и прочих контейнеров не призвана как раз нивелировать данный мелкий недостаток?
Gorthauer87
23.11.2015 15:21+12Мне кажется, что позиционирование себя как «программиста на языке х» вообще изначально ущербно. Синтаксис, концепции, парадигмы они во многих языках схожи, есть исчисляемое количество подходов к написанию программ. Сильно ли визуально отличается код на Java, C++, C#?
Если есть база, то новый язык выучить не так уж и сложно, не сложнее, чем очередной фреймворк. Сложнее понять новую парадигму, другую модель памяти.
96467840
23.11.2015 16:40+4а опыт, а ньюансы? чем больше кода пишешь на языке тем продуктивнее становишься. новый язык все равно будет не привычен.
Gorthauer87
23.11.2015 17:27-2На голом опыте далеко не уедешь, можно быстро превратится в телефонистку или представителя какой-нибудь ещё вымершей профессии.
Flammar
23.11.2015 18:14+3Сильно ли визуально отличается код на Java, C++, C#
По какому-то странному стечению обстоятельств перечислены только языки со строгой типизацией, а два из них так и вообще безопасные;-)
Если из списка отбросить C++, то оставшиеся два — точно не столько из серии «программист на языке х», сколько из серии «программист под платформу y», позиционирование себя как «программиста под платформу y» уже не ущербно. А вот PHP, Python, JavaScript, Visual Basic — это да, «программист на языке». C++ такой большой, что сам как платформа. Но и то тут рпаспадается на области: PHP, Python, Node JS — это «веб», JavaScript (безальтернативно) — «клиентский веб», Visual Basic — «под Windows», C++ — «под Windows» и «низкоуровневое». Так что у тех, кто «на языке», есть смежная область, куда можно расширять кругозор…SamDark
23.11.2015 18:18+1Нода не только веб (кстати, не самая популярная для серверсайда платформа). Это ещё сокетные бэкенды и консольные тулзы (особенно для фронтенда).
father_gorry
23.11.2015 15:37-3Вот и отечественный язык Parser-3 находится едва ли не в худшем положении. Многие до сих пор принимают его за шаблонизатор Parser-2, который закончился в далеком 2002м, а кто-то до сих пор ассоциирует с полной багов поделкой Parser первой версии. В то время как это тьюринг-полный объектный язык, поддерживаемый и развивающийся, а встроенность конструкций в html и возможность покраски данных делают его едва ли не лучшим языком для веб-разработки небольших проектов.
NeonXP
23.11.2015 16:55встроенность конструкций в html и возможность покраски данных
А разве не за это раньше ругали PHP? Ну или ругают, те, у кого знания о РНР >= 10 летней давности. Это уж точно не повод для гордости и не аргумент за «лучшесть для веба».
Для динозавров: PHP сейчас слава б-гам уже давно отошел от этой парадигмы, если что. Сейчас HTML только через шаблонизаторы принято делать.father_gorry
23.11.2015 17:30Возможно, в случае с PHP тогда проблема была в его кривости, а не во встраиваемости. Я видел и то и другое, меня коробит от встроенных <? но конструкции с ^ выглядят вполне читабельно, особенно если правильно подсветить.
Хотя скорее, дело в том, что мы слишком увлеклись MVC, и спешим выбросить всё, что в него не укладывается.Adelf
23.11.2015 19:44Эх, а я так надеялся, что ваш первый коммент про Parser был сарказмом :) было бы гораздо смешнее
father_gorry
24.11.2015 09:59+1Ну вы же понимаете, что высмеивание — это аргумент самого низкого качества.
NeonXP
24.11.2015 01:12Меня тоже коробит от <?, поэтому в моём коде всегда ровно один <?php в начале файла и никаких ?> (и то, он проставляется автоматически PhpStorm'ом). С html работает шаблонизатор twig, в котором синтаксис, ИМХО, гораздо органичнее вписывается в html, чем php или тот же parser.
И да, посмотрел на сайт парсера, судя по датам релизов, он уже начинает отдавать мертвичинкой. А слова apache и cgi заставили нервно дёрнуться. Как в этом вообще можно жить?father_gorry
24.11.2015 11:10Как жить? Если это помогает решать задачи лучше чем другие варианты, то вполне комфортно. Сейчас все популярные инструменты перешли в раздел командной разработки, с максимально жесткой типизацией, многоуровневыми библиотеками объектов и ограничением тех практик, которые в командной работе могут приводить к хаосу. Их даже стали называть «плохими практиками», придав определению характер абсолюта, безусловности.
Но для индивидуального разработчика все эти вещи только тормозят работу. Всё, что ему нужно — готовая среда и управление видом страницы в коде. Как Arduino.
grevus
23.11.2015 16:00+4Это так забавно. Иногда складывается впечатление, что проблема PHP-программистов в том, что они PHP-программисты.
Поясню.
Официально я PHP-программист. Т.е. зарабатываю этим денег. Много.
Но я могу говнокодить на любом языке программирования. Из недавнего вот приходилось на Erlang, C++ и, конечно же, bash script.
Я уж не говорю про Питон, Руби и ещё тут ваше название. Может на brainfuck с разбегу не напишу, но уверяю вас через час тоже наговнокодю.
Любой язык это инструмент. Любой инструмент нужно знать и уметь пользоваться.
До смешного доходит, когда люди узнают, что в языке есть такие конструкции:
// Контекст: опции передаются в консольный скрипт if ($this->getOpt()->{'log-path'}) return $this->getOpt()->{'log-path'};
Начинают к языку отношения менять (сарказмЪ).
Если ты не знаешь, что такое кеширование, ORM, паттерны, какая разница на чем писать?
Проблема не в языке, а в образовании, как бы не банально это звучало.ShadowsMind
23.11.2015 17:57Но Вы же прекрасно понимаете, что таких PHP разработчиков как Вы сравнительно маленький процент, в отношении тех кто дальше PHP никуда не смотрел. Как показывает практика, люди, нашедшие в себе силы, изучив любой другой язык, на PHP назад почти не возвращаются. Отсюда риторический вопрос — «Почему!?».
Изучение новых технологий, платформ, языков всегда дает плюс, хотя бы с точки зрения знаний альтернативных решений той или иной задачи.
P.S. сам начинал писать на PHP. Вовремя перешел на Java, последние пол года очень зацепила Scala. Ни один день в своей жизни не жалел, что инвестировал свое время в изучение новых языков.sam002
23.11.2015 18:07Три-четыре последние года следую схеме «каждый год изучить новый ЯП». Писал и на Java, и понравилcя Scala, но реально пригодилися только узкоспециализированный R.
Как по мне, так специализацию надо строить от области применения знаний, а не стека технологий. Вэб сейчас ограничен php/python/js/ror.ShadowsMind
23.11.2015 18:55Полностью с Вами согласен. Когда люди не понимают, что для решения какой-либо задачи проще что-то освоить и сделать правильно — городят костыли, а потом еще и удивляются что их (и попутно их технологию) критикуют.
SamDark
23.11.2015 18:20+5Перешёл с Java на PHP для веб, ни разу не жалел :)
ShadowsMind
23.11.2015 19:14Не нужно выдавать исключение из правил за повсеместное явление )
Плюс ко всему, Вы видимо хорошо понимаете Ваши задачи и для чего конкретно Вам нужен PHP. А не просто потому-что «мне на форуме подсказали что PHP рулит и теперь буду со всеми спорить и говорить что он самый хороший, хотя даже не знаю с чем сравнить» (с)
bo883
23.11.2015 21:25Александр что с подвигло на переход?
SamDark
23.11.2015 21:44+51. Относительно сложный и не быстрый билд и деплой.
2. Spring и тяга всей команды делать в приложении столько же слоёв, сколько там… а лучше ещё больше. Wicket был получше, но ынтырпрайзить от этого не перестали.
3. Дебаг Hibernate, нахождение бага в нём и попытка его поправить.
4. Конфиги в XML адовой вложенности.
5. «Отличное» отношение к вопросам на всех форумах кроме доброго лося.
6.…
grevus
23.11.2015 18:46+1Ну, это у кого как путь лег.
Я начинал с Visual Basic + ASP, потом микроконтроллеры (хотя это не очень честно, там был «визуальный» язык программирования).
Потом c++. А потом PHP. Хочу уточнить, что это мой путь только с коммерческой точки зрения. Я получал за это деньги. И остался на PHP.
Так получилось, что я лучше всего знаю как готовить именно его.
Так что я из тех, кто ушел в PHP. Да, много знакомых уходит, изучив новый ЯП. А потом пишут о проблемах с версиями в питоне, отсутствием окружения для явы на продашене, криворуких писателей библиотек для C++ и т.д.
Учить язык, не обязательно. Нужно просто всегда учиться. Узнавать что-то новое.
Каждый делает как может. Кто-то делает интерпретатор brainfuck на php.
Мне проще столкнуться с задачей и решить её новыми инструментами или почитать умных людей.
Нужно просто инвестировать своё время, как вы правильно выразились. А уж в новые языки, чтение Робина Мартина, или интерпретаторы, это кому что.
shoomyst
23.11.2015 19:37По всей видимости ваша «практика» касается в основном студентов, которые 2 месяца пописали на php, а потом решили, что php это не солидно, когда остальные пишут на крутых JS/Ruby/Scala.
Изучение JS не заставило меня переписать всё на Node.js. Изучение питона с его костылями вроде GIL и подчеркиваний для приватных свойств было увлекательным, но не более того. Примерно то же самое можно и про Java и Go сказать. Нормальные инструменты для своих задач, но отнюдь не повод отказываться от php, тем более имея большой опыт его готовки и зная большинство его подводных камней и ограничений.
Dominis
23.11.2015 20:36Как показывает практика, люди, нашедшие в себе силы, изучив любой другой язык, на PHP назад почти не возвращаются. Отсюда риторический вопрос — «Почему!?».
Возможно потому, что как здесь уже говорили — php хорош как язык для начинающих, ибо «начать делать» можно быстро. С Си, Джавой и прочими «Мощными и проверенными временем» решениями не сравниться. Мой опыт веб-программирования начался с php. Можно сказать от скуки решил сделать маленький полезный проект, взял книжку, читал её три дня, а потом начал кодить и недельки за две уже было годное под мои задачи приложение. При полном отсутствии опыта разработки под веб до того времени. Думаю мало какой ещё язык позволяет так легко начать делать что-то реальное (для себя). Потом я увлёкся вебом, пару лет писал на пхп, но познакомился с пайтон-джанго. После Joomla это было невероятно круто. А дальше началась полноценная разработка под веб, пришлось заняться фронт-эндом, а потом и нодой. В итоге сейчас мне порой любопытно чтож там твориться-то в пхп. Однако есть гораздо более интересные вещи на которые и трачу время, а к пхп вернутся нет стимула. И дело не в языке. Мы в компании используем иной стек технологий, так что мне это просто не к чему. Думаю у многих ситуация схожая. Когда пхп первый язык, то возвращается к нему поздно — т.к. ты уже не одиночка и надо оглядываться на команду.
P.S. По теме топика — мне кажется, зачастую нападки на язык больше из-за людей, которые на нём пишут. Всё-таки я очень много встречал упоротых Пыхеров (я иначе их не назову, без обид) которые ничего кроме раздражения не вызывают. И язык на котором они пишут виноват только в том, что он в начале прост настолько, что даже упоротые быдлокодеры смогли им овладеть.
ginx
24.11.2015 23:01+1Кто-то писал, что перешел с PHP на Go, но после того как в PHP 7 появились новые фичи (в особенности поддержка статической типизации) вернулся обратно в PHP )
ShadowsMind
25.11.2015 11:04-1Вы же на основании новости о том, что кто-то упал с 10го этажа и остался жив, не сделаете вывод, что 10 этаж это вовсе не высоко и можно падать не боясь разбиться!? )
defuz
23.11.2015 23:45-3Почему самоущещение автора и других PHP разработчиков должно изменить мое отношение к этому языку? Каким образом использование PHP в Facebook делает его хорошим языком? Язык – это спецификация. И язык PHP – это плохой язык. Объективно плохой. И если специалист не может смирится с этим фактом, пользуйясь принципом «все равно его не брошу потому что он хороший», то тогда профессиональность такого специалиста можно поставить под сомнение.
«На удивление хорошо знаешь информатику для PHP-разработчика»
В чем вина человека, сказавшего это, если большинство PHP-разработчиков объективно плохо знают информатику?VolCh
24.11.2015 00:40+1Языки уже дано не только и не столько спецификация, а сколько конкретные реализации и сложившиеся вокруг них экосистемы.
В чем вина человека, сказавшего это, если большинство PHP-разработчиков объективно плохо знают информатику?
И у вас есть объективные данные, конечно же?defuz
24.11.2015 01:07-2«Языки уже дано не только и не столько спецификация, а сколько конкретные реализации и сложившиеся вокруг них экосистемы.
В более широком смысле – да, только что это меняет? По сравнению с другими языками у PHP впечатляющая реализация? Или фантастическая экосистема?
И у вас есть объективные данные, конечно же?
К сожалению, я не занимаюсь аналитикой в подобных вопросах, но могу попробовать порассуждать логически и объяснить, почему такое утверждение мне кажется истинным. Даже в статье есть некоторые факты, которые указывают на это: „есть несколько причин, по которым новые разработчики выбирают PHP...“
Я думаю, вы не будете спорить, что начинающие разработчики хуже разбираеются в computer scince, чем опытные? Именно эти начинающие, которых в PHP больше, чем в других языках, портят статистику для PHP: средний PHP разработчик выглядит менее образованным на фоне разработчиков на других языках. В качестве показательного контрпримера возьмите Haskell – мало для кого этот ЯП был первым, или даже вторым.
Так что это тоже самое, что „средняя женщина управляет автомобилем хуже, чем средний мужчина“ или „средний чернокожий зарабатывает меньше, чем средний европеоид“. Кому-то эти утверждения могут показаться не очень тактичным или приятным, но от этого они не становится менее объективными, потому что есть общая тенденция.VolCh
24.11.2015 02:45Или фантастическая экосистема?
Не фантастическая, но очень и очень конкурентоспособная. Только связка LAMP+WordPress чего стоит.
Именно эти начинающие, которых в PHP больше, чем в других языках
Голословно. Как по мне, то куда больше начинающих на JavaScript. И начинающие на PHP разбираются в информатике, как правило, лучше начинающих на JavaScript по объективно-статистическим причинам: PHP в подавляющем большинстве случаев используется в связке «клиент-сервер» или в трехзвенной архитектуре, а JS — только на клиенте.
средняя женщина управляет автомобилем хуже, чем средний мужчина
Вроде как статистика опровергает.defuz
24.11.2015 12:27+1Не фантастическая, но очень и очень конкурентоспособная. Только связка LAMP+WordPress чего стоит.
Насколько мне известно, стало действительно приемлемо за последние годы, но это точно не козырь PHP. Как-то не вижу я толп желающих пересесть не PHP из других языков, потому что у PHP хорогая экосистема. Может не туда смотрю?
Что такого особенного в связке LAMP+WordPress я вообще не понимаю. Объясните?
Голословно. Как по мне, то куда больше начинающих на JavaScript.
Может быть, но как по мне что PHP, что Javascript – два сапога пара. Извините, но в «javacsript все еще хуже» – это не сильный аргумент. Я оба языка считаю не удачными. И javascript тут оправдывает только то, что альтернативы к сожалению нет.
Вроде как статистика опровергает.
Как скажете.DrPass
24.11.2015 12:58> Что такого особенного в связке LAMP+WordPress я вообще не понимаю. Объясните?
Я с нулевым опытом в веб-дизайне могу сесть и сделать за день сайт, такой же, какой профессиональная студия сделает за месяц и много денег. Мой сайт будет выглядеть профессионально, поддерживать разные броузеры и размеры экранов и т.д. Да, он будет тяжелым и тормознутым. Но во многих случаях клиент смотрит на внешний вид.
Это такой себе Delphi для веб-разработчиков.poxu
24.11.2015 13:27Я с нулевым опытом в веб-дизайне могу сесть и сделать за день сайт, такой же, какой профессиональная студия сделает за месяц.
Не сможете. Вернее сможете, но если вы вообще не будете делать свой дизайн.
и много денег.
Да, много денег возьмут, есть такая тема.
Мой сайт будет выглядеть профессионально, поддерживать разные броузеры и размеры экранов и т.д. Да, он будет тяжелым и тормознутым.
Обратите внимание, вы только что стали php разработчиком. Потому, что получили деньги за работу с php. А потом люди удивляются откуда о php разработчиках предвзятое мнение.
Но во многих случаях клиент смотрит на внешний вид.
Не во многих случаях, а всегда.DrPass
24.11.2015 15:04> Не сможете. Вернее сможете, но если вы вообще не будете делать свой дизайн.
«Свой дизайн» — не смогу. Но полезность Вордпресса как раз в том, что он избавляет от необходимости делать свой дизайн. Я смогу купить за сумму порядка $50 одну из множества гибко настраиваемых и профессионально сделанных тем, и мышкой настроить её так, как будет красиво. И заказчик будет доволен, он не увидит внешней разницы между «разработать и сверстать» и «нарисовать мышкой».
> Обратите внимание, вы только что стали php разработчиком. Потому, что получили деньги за работу с php.
> А потом люди удивляются откуда о php разработчиках предвзятое мнение.
Ну как сказать… вот Libre Office написан на C++. Означает ли скачивание этого пакета и создание документов в нем то, что вы стали разработчиком С++?
WordPress — это прикладное приложение, среда для быстрой разработки сайтов вообще без навыков веб-разработки. Конечно же, зная PHP и JavaScript, вы можете делать сайты в ней лучше, преодолевать ограничения тем и самой среды, но прелесть WordPress как раз в том, что это знание опциональное, а не обязательное. И это опять ответ на ваш вопрос:
> Что такого особенного в связке LAMP+WordPress
defuz
24.11.2015 13:47-2И это что, какая-то уникальная фишка Wordpress и того, что он написан на PHP? Может быть Wordpress действительно в этом неплох, но я могу ровно тоже самое сделать и на другой платформе.
А PHP тут как-то вообще не причем.
defuz
23.11.2015 23:54-1Честое слово, детский сад какой-то. Что автор вообще хотел сказать? «Пожалуйста, не критикуйте больше мой любимый язык, потому что мне от этого грустно и обидно»?
«После такого задаешься вопросом — а не выбрал ли я плохой язык?»
И каков ответ? Или такой шквал критики на PHP вы оправдываете тем, что он такой популярный, а другим завидно?SamDark
24.11.2015 04:33+2Кстати, вполне вписывается :) 81.6% всех веб-проектов бегает под ним. Работы на менее популярных языках меньше. Обидно! :)
defuz
24.11.2015 12:37-1Не обидно, потому что на других языках задачи обычно гораздо интереснее, а спрос не сильно меньший (в пересчете на к-во владеющих языком).
SamDark
24.11.2015 14:40+1Ну как это не обидно, если такая реакция? PHP-шники недопрограммисты заняли рынок и отбивают работу у крутых адептов языка X, не?
defuz
24.11.2015 15:03-2Да никто не отбирает работу, успокойтесь. Прямо сплю и вижу, как пхапешники вымрут, и я наконец смогу клепать блоги и интернет магазины на PyWordPress и PyJoomla. Но наступает утро, и я c унынием иду писать асихронные сервера на python, которые держат тысячи соединений на процесс и успевают еще делать machine learning. Аж зубы от злости сводит, ага.
defuz
23.11.2015 23:59-2Я думаю, стоит также добавить, что автор статьи всю свою професиональную жизнь писал только на PHP и Javascript. Выводы, что называется, делайте сами.
ginx
24.11.2015 06:55+3По поводу concurrency в PHP:
'Parallel PHP' намечается в следующих релизах (возможно 8).
Multi-threading в PHP возможно использовать уже сейчас с pthreads:
Asynchronous Concurrency - Vanilla PHP<?php class Task { function Task($id, $start, $end) { $this->id = $id; $this->start = $start; $this->end = $end; $this->pos = $this->start; } function execute() { if ($this->pos < $this->end) { return $this->pos++; } else return false; } } $range = range(1, 100); $ranges = array_chunk($range, 10); $tasks = array(); while (count($ranges)) { $range = array_shift($ranges); $tasks[] = new Task( count($tasks) + 1, array_shift($range), array_pop($range)); } while (count($tasks)) { foreach ($tasks as $id => $task) { if ($task->execute() === false) { printf("task %d complete\n", $task->id); unset($tasks[$id]); } else printf("task %d position %d\n", $task->id, $task->pos); } } ?>
Daniro_San
24.11.2015 09:23$LovePhp
$phpIsHTMLtemplate
И его синтаксис, особенно создание переменных.
achekalin
24.11.2015 09:55-8Слушайте, тенденция брать статьи, переводить, даже забыв про копирайт, и публиковать, тупо внизу написал что угодно про свою компанию — она прямо вымораживает мозг. Конечно, важно взять больную тему, такую, чтобы побольше комментов было.
Рецепт прост: платим за аккаунт, и на наши похождения никто криво уже не посмотрит. Публикуем что угодно, лишь бы собрать аудиторию. В конец пишем любую ересь, но со ссылкой про себя.
Помните, как в анекдоте: «Это рыба, и шерсти у нее нет. Но если бы шерсть была, то в ней жили бы блохи — и далее про блох».
Не стыдно за (видимо, когда-то любимый) ресурс, товарищи платноаккаунтщики?
P.S. А ссылку на оригинал и указание «перевод» — этому вас не учили, профи от мира электронных платежей («проекта который, поможет подключить вам на сайте прием платежей или массовые выплаты» — хоть Word натравите на фразу, чтобы запятые расставить)?
cigulev
24.11.2015 10:49+7Утверждаете, что Хабр любимый ресурс, но пользоваться им не умеете. Объясняю:
Вот сюда кликаешь и попадешь на источник, это не мы придумали, так устроен якобы любимый вами ресурс. Хотя судя по вашему профилю любовь у вас не взаимная.achekalin
24.11.2015 18:19-6Вообще, если вы читаете внимательно, где во фразе
> Не стыдно за (видимо, когда-то любимый) ресурс, товарищи платноаккаунтщики?
упоминается моя любовь к ресурсу? :) Я как раз и не очень рад, что очередной холиварной текстовкой откровенно привлекают внимание к сайту компании. А насчет ссылки на оригинал — да, она не сказать чтобы бросается в глаза, это так. После очередной «удачной» смены дизайна не всегда легко найти привычные элементы.
Но вернемся к основной моей мысли. Мы с вами без труда придумаем еще десяток отличных холиварных тем, для продолжения пиара веб-пеймента. Скажем, «а я ушел с линукса на винду, потому что я так привык, и не надо мне тыкать, что я не профи», «оказывается, апач — не единственный веб-сервер», «безопасность придумали трусы, просто надо хранить данные в куках зашированными» и прочее. Нужен ли нам хабр с таким подходом к наполнению? Не думаю. Назвать ли его, наполняемого таким образом, «любимым» мною (как вы мне приписали)? Хм, это определенно не тот по духу ресурс, которым он был в начале.
Хорошо, а вы-то сами как относитесь к логике «ссылки не пахнут»?
dcc0
25.11.2015 00:54-3Одна из первых причин, которая многих раздражает вполне конкретна — PHP — динамические типы данных.
Ссылка на хабр же: http://habrahabr.ru/post/259497/
И это усложняет разработку, это усложняет изучение языка. Это чаще заставляет пользоваться справочником PHP, иногда посматривать в историю версий, так как многое запоминать не хлочется. То, что PHP для начинающих, — это, возможно, все же миф.
Замечу еще, что на php написана хорошая доля бразуерных игр, многие из которых очень даже успешные коммерческие проекты.
Еще один жирный + языка возможность очень быстро развернуть почти на всем какую-старую версию языка, если надо потестировать или изучить функционал какого-то старого движка. Не спешите кричать «а зачем оно надо?». Мне попался игровой движок, который начинал писаться лет 10 назад, писался явно разными программистами, тут закомментированный императивный код, вместо него ООП, смесь и того и другого. Движок для версии 5.2. Три дня работы, нет не мучений, именно работы и я запустил его на версии 5.6.
Еще один + — для браузерных динамических масштабируемых игровых проектов PHP почти идеален.
Спасибо. Вот теперь пинайте.
Fesor
25.11.2015 05:06И это усложняет разработку, это усложняет изучение языка.
изучение языка оно не усложняет, оно увеличивает возможность накосячить.
в целом возможно вам будет интересно что в PHP7 можно писать так:
function foo(string $bar) : string { return str_replace('bar', 'foo', $bar); }
akubintsev
25.11.2015 12:01+21. Мне без разницы мнение каких-то личностей о профессиональном инструменте, благодаря которому у меня нет проблем с поиском работы и достойным вознаграждением.
2. PHP меня полностью устраивает своими возможностями и темпами развития.
О чём еще можно разговаривать тогда с хейтерами?poxu
25.11.2015 12:07О недостатках php. Если вас всё устраивает в каком-нибудь языке программирования это скорее всего означает, что вы на нём не программируете :). С темпами развития, да прикольно. Можно расти вместе с языком.
VolCh
25.11.2015 12:16Есть разница между «устраивает возможностями» (хотя лично мне многого не хватает «из коробки») и «всем устраивает».
akubintsev
25.11.2015 12:56Я бы сказал, что если меня устраивает язык программирования, значит я делаю на нём то, для чего он предназначен. В данном случае классические веб-сервисы и иногда демоны с асинхронной работой. И не использую php например для системного скриптинга или для десктопных приложений.
А синтаксис — дело привычки, но php и не многословен по сравнению с некоторыми иными.Fesor
25.11.2015 13:38Человек имел в виду что инструменты без проблем, это те, которыми не пользуются. У всех инструментов есть свои проблемы, свои сферы применениия где они показывают себя наиболее эффективно, и где не очень эффективно, ну и все такое.
akubintsev
25.11.2015 17:04С таким же успехом можно было утверждать, что в мире ничто не идеально :)
Но у меня больше почему-то возникает вопросов как бы проще написать тот или иной функционал, чтобы не усложнять чрезмерно, но и не скатиться в говнокод. А с особенностями языка крайне редко заморачиваюсь.
dcc0
29.11.2015 01:20Очень хорошо язык знают те люди, которые его разрабатывали, а они его ругать не будут.
Что значит знают хорошо? И что ругают? Синтаксис языка? Он прекрасен.Понятен и очень прост.
Логику языка? Это пустое и странное занятие.
Что ругать? Сам интерпретатор? То как он работает? Это тоже странно, с учётом того, что в исходники, скорее всего за все время существования php, смотрели только разработчики.
Что ругать в итоге?
Код, который пишут новички и непрофессионалы?
Про новичков — никто пока не начал программировать, только появившись из утробы матери.
Про непрофессионалов — это явление вечное.
И где та тонкая грань между профи и непрофи?
Ругань php остается списать на антипропаганду достаточно открытой технологии.DrPass
29.11.2015 02:32-2Причины ругать всегда есть. Я не претендую на звание знатока РНР, но даже я могу невооруженным взгядом видеть проблемы. Синтаксис РНР прекрасен? Нет, не прекрасен. Он имеет как минимум один жуткий косяк в виде отсутствия строгой типизации. Ругать интерпретатор тоже есть за что. Как он внутри работает, я… ну скажем так, заглядывал в конце 2000-х. После распутывания макросов С++ где-то на седьмом уровне вложенности осознал, что разработчики — нездоровые фрики, и развивать ЭТО можно только полным переписыванием с нуля. И вероятно отсюда вытекает и внешний недостаток интерпретатора, это отсутствие нормальной совместимости между версиями. Кстати, и открытость тоже тут становится неактуальной. Ну не будет никто в нем править баги…
Fedot
29.11.2015 12:39+1Как у вас получается соотносить синтаксис и строгую типизацию?
Это две абсолютно не связанные вещи. Строгая типизация это не признак синтаксиса, это признак языка.
По поводу кода, PHP написан на C, откуда там макросы из C++? На плюсах можно только расширения писать, но не основной код языка PHP.
Fesor
29.11.2015 13:01+1Синтаксис РНР прекрасен? Нет, не прекрасен. Он имеет как минимум один жуткий косяк в виде отсутствия строгой типизации.
1) синтаксис вменяем (сравните с bash или perl, хотя и тут найдутся не согласные, это весьма субъективная оценка).
2) строгая типизация никакого отношения к синтаксису не имеет, и это сомнительный плюс (ну то есть это клево но пораждает свои проблемы, и учитывая особенность сферы применения php — на пользу это никому не пойдет). Есть тайп хинтинг (в том числе и для скаляров и для возвращаемых значений), возможно вскоре появится тайпхинтинг для свойств объектов и т.д. (в Hack например).
Как он внутри работает, я… ну скажем так, заглядывал в конце 2000-х.
И что вы там ругать собрались? Примитивная виртуальная машина (каждому опкоду соответствует просто какая-то функция виртуальной машины, так все интерпритаторы устроены), с php7 вместо кастыльного парсера у нас уже адекватный парсер использующий промежуточное представление (абстрактное синтаксическое дерево). Словом… я в коде PHP конечно странные места находил, но видал и похуже.
Ну и опять же, за последние лет 5 много чего сделали. Самые большие изменения в нутрах PHP произошли с выходом PHP 5.4, там множество оптимизаций было внедрено.
После распутывания макросов С++ где-то на седьмом уровне вложенности
макросы это чисто сишная штука, и чисто для упрощения разбора кода. Вы видимо не смотрели исходники CPython, Ruby MRI и т.д. Из сишных проектов которые мне довелось смотреть только постгрес может показаться идеальным.
ЭТО можно только полным переписыванием с нуля
FYI в php 7 все внутренние структуры используемые для рантайма были переделаны, почти все ядро переписано.
это отсутствие нормальной совместимости между версиями
вы о чем вообще? нет никаких проблем с совместимостью между версиями.
вобщем резюмирую, вы видимо вообще не представляете о чем говорите. Либо вас переполняют эмоции а это опять же говорит о том что объективно оценивать что там так или не так или нужно переписывать вы не можете.DrPass
29.11.2015 13:35-2> Как у вас получается соотносить синтаксис и строгую типизацию?
Вы хотите сказать, что правила определения типов данных не является частью синтаксиса языка? Браво.
> Ну и опять же, за последние лет 5 много чего сделали.
Я рад за ваш прогресс. Если бы вы не вскипели благоверной яростью за любимую игрушку после первых четырех слов, то увидели бы дальше по тексту, я там написал, что смотрел исходники PHP в конце 2000-х, и что я не являюсь экспертом по РНР.
> макросы это чисто сишная штука, и чисто для упрощения разбора кода.
Да вы что? А я-то думал, что макросы в сишных исходниках пхп — это не сишная штука :) Так, к сведению, многкратная вложенность макросов в коде — это для усложнения разбора кода.
> вы о чем вообще? нет никаких проблем с совместимостью между версиями.
Странно. А чего тогда переписывали сайты с версии 4 на 5?
> вобщем резюмирую, вы видимо вообще не представляете о чем говорите. Либо вас переполняют эмоции
В общем, резюмирую: я задел ваш любимый проект, и вы тут же расчехлили свой какашкомёт и кинулись в холивар. Угомонитесь. Я не собираюсь ни ругать, ни хвалить пхп. Я им уже давным-давно не пользуюсь, и особо и не наблюдаю за его прогрессом. Я просто привел предыдущему оратору пример, почему не надо бездумно хвалить технологии, при этом подчеркнув, что моя информация — семилетней давности. Не более того.Fesor
29.11.2015 14:32не является частью синтаксиса языка? Браво.
Нет, я хочу сказать что вы подменяете понятия. Синтаксис языка это вообще весьма вторичная штука, в то время как система типов это уже интереснее. А вопрос статическая/динамическая типизация это холивар которому уже лет 20.
PHP в конце 2000-х, и что я не являюсь экспертом по РНР.
Вот этот фрагмент который вы процетировали я как раз по этому поводу и описал.
это не сишная штука :)
вы сказали что это C++ ные штуки, есть разница
это для усложнения разбора кода.
FYI это позволяет нехило так DRY-ит код, упрощать его и т.д. Хэндлить такие нюансы как различия с big/little endians, и куча других вещей. В Си подругому как-то не особо получается писать и так написаны почти все проекты на Си. Возможно 7 лет назад код PHP был намного хуже, я не спорю, но думаю что примерно так же. Как никак Расмус и его други Сишники. А проблема PHP в том что изначально его не проектировали как язык программирования.
Странно. А чего тогда переписывали сайты с версии 4 на 5?
Потому что между php4 и php5 разница существенна, но не настолько существенна как между python2 и python3. Так что… все относительно. Да и на тот момент небыло таких инструментов как php-parser и т.д.
я задел ваш любимый проект, и вы тут же расчехлили свой какашкомёт и кинулись в холивар.
вы сдедали вброс, я прокоментировал.
почему не надо бездумно хвалить технологии
Так а кто-то хвалит?) Я против как хэйта так и нахваливания так как в этом всем нет ни капли объективности как правило. В целом же именно с этой мыслью я полностью с вами согласен.DrPass
29.11.2015 14:49> Нет, я хочу сказать что вы подменяете понятия. Синтаксис языка это вообще весьма вторичная штука,
> в то время как система типов это уже интереснее.
Если вы решили углубиться в детали, то «система типов» — это их состав, организация и размерность. Правила описания типов и собственно их наличие — это синтаксис в чистом виде.
> вы сказали что это C++ ные штуки, есть разница
Вы знаете, если вы пишете код на С++ и используете там что-то, что понимает препроцессор компилятора С++, то это часть языка С++. Даже если она туда перекочевала ранее из языка С.
> FYI это позволяет нехило так DRY-ит код, упрощать его и т.д.
… если использовать с умом. Все языковые конструкции существуют исключительно из чьих-то благих намерений сделать лучше, упрощать и т.д. Проблемы возникают с теми, кто их использует коряво. Нет ничего плохого в макросе, макрос — это хорошо. Но когда макрос использует макрос, а тот макрос использует другой макрос, а другой еще, и продолжите цепочку несколько раз… это не упрощение кода. Это программист, у которого увлечение абстракциями затоптало здравый рассудок.
> Потому что между php4 и php5 разница существенна
Ок. Теперь давайте назовём это проблемой с совместимостью между 4 и 5 версиями, ладно? ;)Fesor
29.11.2015 23:12Даже если она туда перекочевала ранее из языка С.
Никуда оно не перекочовывало, оно написано на Си и собирается через gcc (а не g++). Тот факт что вы можете собрать php через компиляторы C++ является лишь следствием совместимости C++ и Си. В прочем это на самом деле все не столь важно. Мне было просто любопытно почему C++.
Это программист, у которого увлечение абстракциями затоптало здравый рассудок.
Ну я сейчас сходу не смогу вспомнить где там что-то такое есть, а то что я видел в принципе нормально коррелировалось со всем этим. Вместо макросов там можно было использовать просто функции, но только производительности ради нужно было просто заинлайнить это дело + упростить код что бы уменьшить количество проблем связанных с совместимостью между разными платформами.
проблемой с совместимостью между 4 и 5 версиями, ладно? ;)
Ну это не проблема, именно из-за нарушения обратной совместимости (не так уж и глобально) это мажерный апдейт (семвер все-таки). Оно всегда проблема обновляться на мажерный релиз. Python2 и Python3 вообще не шибко совместим оказался и народ лет 5 перебирался. И им норм.
poxu
30.11.2015 11:26+11) синтаксис вменяем (сравните с bash или perl, хотя и тут найдутся не согласные, это весьма субъективная оценка).
Верное замечание. Всегда надо сравнивать языки в рамках одной и той же категории. Действительно, чего сравнивать с java то, что больше похоже на bash. Думаю надо пойти дальше. Думаю надо сравнить с brainfuck. Логика в общим понятна. Аутсайдеров надо сравнивать с другими аутсайдерами, а не с лучшими представителями области.
2) строгая типизация никакого отношения к синтаксису не имеет
Внезапно.
и это сомнительный плюс
О как. Ну с точки зрения тех, кто этой типизацией не пользуется, может и правда сомнительный.
(ну то есть это клево но пораждает свои проблемы, и учитывая особенность сферы применения php — на пользу это никому не пойдет).
Вы видимо хотите сказать, что задачи, стоящие перед php разработчиками настолько примитивны, что строгая типизация погоды не сделает?Fesor
30.11.2015 12:11Я хочу сказать что тайп хинтинг решает почти все проблемы возникающие в следствии динамической типизации. Тут вам и статический анализ, и многое другое. С другой стороны динамическая система типов позволяет не сильно замарачиваться внутри и позволяет быстрее писать простой код (коего на php пишется сегодня подавляющее большинство). А так, с тех пор как появился тайп хинтинг для скаларов и режим строгого соответствия типов для аргументов (не по умолчанию), думаю проблем станет чуть меньше.
Хотя справедливости ради даже на момент php7 тайп хинтинг не покрывает все так что бы можно было на 100% вычислить типы всего и вся используемые, но может быть в 7.1 (или рядом) сделают дженерики и жизнь улучшится. В целом я подозреваю что в итоге будет точно так же как в Hack.poxu
30.11.2015 12:42Тайп хинтинг — хорошо конечно. Но система статической типизации конечно лучше.
С другой стороны динамическая система типов позволяет не сильно замарачиваться внутри и позволяет быстрее писать простой код (коего на php пишется сегодня подавляющее большинство).
А можно пример кода, который будет проще, если использовать динамическую систему типизации? Я такого придумать не могу чего-то.Fesor
30.11.2015 13:15Я такого придумать не могу чего-то.
Я если честно тоже, потому что не люблю так писать) у меня переменные обычно сохраняют свой тип (я даже менять их не люблю). Но даже в C++ уже никто явно типы не описывает и оставляет это дело компилятору вычислять (спецификатор auto).
Я пожалуй все же хотел сконцентрировать внимание что с динамической системой типов нет необходимости парится о том какого типа переменная в данный момент времени. А если у нас код локализован в функциях/методах объектов c тайп хинтингом, и эти функции маленькие, то вычислить типы не представляется проблемой.
Ну то есть для обучения это одновременно и плюс и минус. С одной стороны мы не загружаем людей всякой ересью (вроде теории категорий) и позволяем быстрее писать код (не забывайте что большинство php разработчиков делают всякие там бложики да лэндинги, со всякими wordpress и joomla, стоимость разработки подобного резко бы подскачила вверх в случае усложнения языка и увеличения уровня необходимых знаний). Но с другой стороны тайп хинтинг (правда не будем лукавить, все ок только в PHP7 и то не совсем) решает проблемы для другой категории PHP разработчиков которые пишут серьезные приложеньки, хотя бы от уровня интернет магазина.
То есть сложность инструмента обычно все же коррелируется со сложностью задачи, которую мы пытаемся этим инструментом решить.
dcc0
29.11.2015 02:53-1Никогда не смогу для себя ответить на след. вопрос: где все ругатели, когда технология только появляется?
А большинство ругателей 20 лет назад писали статичные сайты на html и не мечтали о чем-то большем.DrPass
29.11.2015 03:27Вы предлагаете ставить памятник всем технологиям только за то, что они появились? Вроде как нас бесплатно облагодетельствовали, и все должны радостно и молча кушать то, что дают? :)
Fesor
29.11.2015 13:04молча кушать то, что дают? :)
нет конечно, но сегодня это скорее «громко возмущаться и кушать то, что дают». То есть никто даже не пытается разобраться с проблемой, предложить конструктивные решения и т.д. Обсудить их в php internals и т.д. Опенсурс же. Если идея неплохая то ее даже кто-нибудь и реализует.
Но это же так сложно, отнимает много времени и т.д. так что проще просто продолжать возмущаться в комментах и продолжать кушать что дают, или же есть что-то другое, и всеравно ругаться.
dcc0
29.11.2015 23:31100 лет назад мужик ездил на телеге, у которой не было амортизации, представляешь? Как-то ездил и эта телега его кормила. Через 80 лет другой мужик ехал на машине марки Москвич и ругал эту машину.
Десять лет машина без гидроусилитея — дрянь. 5 лет назад, как же мне прожить без коробки автомат7
Наше время, в машине есть, кроме пологрева одного места ( по которому надо бы бить чаще) и опять дрянь.
Из-за разного рода придурков, которые мнят себя гениями, а на деле ни хрена сделать не могут, кроме как скопировать, нормальные люди с очень большим подозрением начинают относится к PHP, да и вообще к программированию… Умерьте свою гордость… свое нахрен никому тут не нужное ехидство… Не нравится PHP, пишите на чем нравится… Зачем вообще лезть в эту ветку?!
DrPass
30.11.2015 00:11+2Полагаю, проблема как с «придурками, которые мнят себя гениями», и которые всё портят, так и с пострадавшими от них несчастными «нормальными людьми» надумана. Никто ни от кого не пострадал.
Но если бы не было людей, недовольных телегами, вы бы и сейчас ездили на телегах. Или ещё того хуже, на машинах марки «Москвич». Как раз критика и недовольные люди двигают вперёд прогресс.
> Не нравится PHP, пишите на чем нравится
Спасибо за совет
> Зачем вообще лезть в эту ветку?!
Это же ваш личный комментарий. Вы его хозяин, поэтому просто удалите мой пост.
poxu
30.11.2015 11:32Зачем вообще лезть в эту ветку?!
Ну, очевидно для того, чтобы ответить на вопрос где все ругатели, когда технология только появляется.
Alexufo
Как говорит Жорес Алферов — тут остались одни оптимисты, потому что пессимисты уехали.