Комментарии 63
Все же
— php быстрее java
— php проще java и позволяет быстрее писать код даже в энтерпрайз, пусть и с оговорками
позволяет этому языку лидировать в мире бакэнд
p.s. вы же знаете что такое java, tomcat, сервлеты,… сборщик мусора… чтобы все еще писать на нем?
— php быстрее java
— php проще java и позволяет быстрее писать код даже в энтерпрайз, пусть и с оговорками
позволяет этому языку лидировать в мире бакэнд
p.s. вы же знаете что такое java, tomcat, сервлеты,… сборщик мусора… чтобы все еще писать на нем?
PHP вряд ли станет языком #1.А оно зачем надо, быть языком номер 1???
Всеобщее признание, деньги, женщины кидают в Вас венки цветов и обсыпают лепестками, восхваляя разработчика на #1 языке.
Там шутейка
Как по мне, то язык программирования — это в первую очередь инструмент разработки. Не думаю, что есть язык, который превосходен во всем. Это как молоток и пилка. Молотком можно прекрасно забивать гвозди, а вот пилкой нет. А вот пилкой можна спилить дерево, молотком же — нет. Это лично мое мнение
Так уж повелось, что выбор языка определяет не сама среда разработки а тот набор фреймворков, которые подходят под задачу и главное их своевременная поддержка.
Да, существуют кросплатформенные фреймворки а так же под одну и ту же задачу существует куча похожих решений, но факт есть факт.
Пример, я сомневаюсь что вы будете писать opencl приложения с использованием php (а ведь такое расширение существует правда без документации и примеров и 8 лет нет развития, точнее есть форки 4-летней давности, т.е. кто то это даже использовал!).
Да, существуют кросплатформенные фреймворки а так же под одну и ту же задачу существует куча похожих решений, но факт есть факт.
Пример, я сомневаюсь что вы будете писать opencl приложения с использованием php (а ведь такое расширение существует правда без документации и примеров и 8 лет нет развития, точнее есть форки 4-летней давности, т.е. кто то это даже использовал!).
Далеко не только технические, скажем так, характристики языков, фреймворков и тулинга влияют на выбор языка и т. п., но вещи типа стоимости разработчиков, наличие их на рынке в принципе, кадровая политика, отношение к аутсорсу, аутстафу, фрилансу, ну и вечный принцип "когда в руках молоток, то всё кажется гвоздём, особенно если нужно вчера" (я на PHP десктоп приложения писал так лет 20 назад ) ).
НЛО прилетело и опубликовало эту надпись здесь
Та ну столько писать человеку (автору), который имеет собственную точку зрения, основанную на его личном опыте, который не коррелирует с большинством всех, кто будет читать эту статью. Всегда будут мода на новые языки, на «энтерпрайзные» языки для «профессссионалов», всегда кто-то будет уходить из какого-то языка из-за того, что он ему не подходит для решения лично его задач, также и будут люди, которые будут слушать/читать мнения других и просто улыбаться, понимая, что язык языком, но бизнесу зачастую плевать на него, бизнес интересует скорость разработки, стоимость разработки и стоимость поддержки кода. Вы все верно сверху написали с технической стороны, я немного дополню со стороны бизнеса: вот в нашей компании мы не будем никогда создавать продукты на Java,C+ и так далее просто потому что это потом выльется в увеличенный бюджет разработки и поддержки, а на php в случае чего я и сам написать на коленке г… код, который будет приводить разработчиков в ужас(не будет, я утрирую), но на 100% будет решит бизнес-задачу и это важнее чем все остальное.
Просто нужно задуматься над вопросом, а был бы сейчас Фейсбук, если бы его начинали писать на Java(представьте любой). Жалеет ли Цукерберг о выборе языка? Это действительно ли проблема php самая большая для Фейсбука? Выиграет ли стартап от того, что запустит сервис на Go(любой модный) и станет ли бизнес процветать от того, что у сервиса «крутой» язык? А так ругать можно все языки, у всех есть минусы. К примеру, условная Jira (или не условная) отъедает более двух гиг оперативки у сервера, а сайт с немного упрощенным функционалом (грубо говоря просто базовый наиболее используемый функционал) на пап при той же нагрузке будет отъедать 0,5 гига оперативки, кто виноват? Java? Или php? Программисты? Нет — те, кто использует технологии продукты не по назначению и если у языка есть крупная экосистема, которая развивается (а не то что происходит в экосистеме nodejs), значит все же у языка есть задачи, которые он решает лучше всего и их много. А говорить, что неизвестно что-то куда-то идёт потому что мне лично непонятно — это как говорить, а кто покупает такие дешевые или такие дорогие машины.
Просто нужно задуматься над вопросом, а был бы сейчас Фейсбук, если бы его начинали писать на Java(представьте любой). Жалеет ли Цукерберг о выборе языка? Это действительно ли проблема php самая большая для Фейсбука? Выиграет ли стартап от того, что запустит сервис на Go(любой модный) и станет ли бизнес процветать от того, что у сервиса «крутой» язык? А так ругать можно все языки, у всех есть минусы. К примеру, условная Jira (или не условная) отъедает более двух гиг оперативки у сервера, а сайт с немного упрощенным функционалом (грубо говоря просто базовый наиболее используемый функционал) на пап при той же нагрузке будет отъедать 0,5 гига оперативки, кто виноват? Java? Или php? Программисты? Нет — те, кто использует технологии продукты не по назначению и если у языка есть крупная экосистема, которая развивается (а не то что происходит в экосистеме nodejs), значит все же у языка есть задачи, которые он решает лучше всего и их много. А говорить, что неизвестно что-то куда-то идёт потому что мне лично непонятно — это как говорить, а кто покупает такие дешевые или такие дорогие машины.
Вы ошибочно посчитали, что главная мысль статьи заключается в том, что «PHP не нужен». При этом даже я сам так не считаю и таких утверждений не писал. Более того, мне нравится и PHP, и то, куда он идет.
О чём статья писалась, так это о том, что PHP пытается быть «серьезным» языком с ООП, дженериками и прочими штуками, что хорошо для энтерпрайза, но противоречит тому, что и сделало PHP популярным: простоте. Потому что если новичок должен для того, чтобы найти свою первую работу, знать кучу всего, то ему сразу очень сложно и очень многие уйдут туда, где проще.
Детальное же сравнение PHP и Java давайте оставим какой-нибудь отдельной статье, я специально не углублялся в детали, чтобы не раздувать текст техническими подробностями. Да и статья бы тогда называлась «сравнение PHP и Java», больно уж много всего придётся затронуть.
О чём статья писалась, так это о том, что PHP пытается быть «серьезным» языком с ООП, дженериками и прочими штуками, что хорошо для энтерпрайза, но противоречит тому, что и сделало PHP популярным: простоте. Потому что если новичок должен для того, чтобы найти свою первую работу, знать кучу всего, то ему сразу очень сложно и очень многие уйдут туда, где проще.
Детальное же сравнение PHP и Java давайте оставим какой-нибудь отдельной статье, я специально не углублялся в детали, чтобы не раздувать текст техническими подробностями. Да и статья бы тогда называлась «сравнение PHP и Java», больно уж много всего придётся затронуть.
НЛО прилетело и опубликовало эту надпись здесь
Да нормальное ООП, ещё с пятёрки, просто это не значит, что надо все в одном стиле писать.
Ну а так, что 10 лет назад, что сейчас, не мешает так же на коленке поднять сервер и начать пилить свой сайтик с знаниями на уровне пару статей почитал, или пол книжки
Потому что если новичок должен для того, чтобы найти свою первую работу, знать кучу всего, то ему сразу очень сложно и очень многие уйдут туда, где проще.
По моему личному опыту у php как раз очень пологая кривая входа. На cms все еще пишут достаточно, да и прочих фриланс задач хватает. А дальше, если захочется, можно учить фреймворки, докеры и т.п. Но уже зацепившись за профессию.
Разрешите вас дополнить!
Треды сейчас в экстеншене parallel. Насколько я знаю с pthreads до сих пор всё плохо.
Сокеты из коробки — fsockopen и stream_socket_server, расширение sockets всё же не идёт в базовой поставке
К асинхронности стоит добавить reactphp, а так же curl_multi и асинхронные драйверы mysql, pgsql.
И ещё, в статье не задевается этот вопрос, но в php появился ffi, который закрывает целый ряд вопросов.
PS: касаемо асинхронности вынужден признать, что с async/await из коробки было бы намного удобнее.
Простым быть уже не получится, там Питон крепко укоренился. Опоздали.
Вот недавно статью видел, по которой можно прийти к выводу, что php для облачных микросервисов с оплатой по ресурсам хорош. При всей оптимизированности Java (может благодаря ей?) памяти она жрёт как не в себя по дефолту…
Если уж меряться ресурсами, то я бы не останавливался на PHP, а взял бы тот же Golang, который (имхо) будет в целом производительнее и куда экономичнее.
А насчёт джавы, то там сразу начинается много вопросов: а как настроили JVM, а какой сборщик мусора взяли и тд и тп. Но да, не спорю, вероятно она будет «есть» больше. С другой стороны, там внутри столько оптимизаций (кстати, стало любопытно и я сходу не смог нагуглить, в PHP есть к примеру векторизация циклов?), то я бы ожидал, что в работе она будет производительнее.
А насчёт джавы, то там сразу начинается много вопросов: а как настроили JVM, а какой сборщик мусора взяли и тд и тп. Но да, не спорю, вероятно она будет «есть» больше. С другой стороны, там внутри столько оптимизаций (кстати, стало любопытно и я сходу не смог нагуглить, в PHP есть к примеру векторизация циклов?), то я бы ожидал, что в работе она будет производительнее.
Я больше про целесообразность перехода (полного или частичного) с PHP на что-то ещё. А уж если переходить, то на Java, имхо, проще всего будет, если нравится "ентепрайзная" часть экосистемы PHP.
Вопросы я старался убрать заранее оговоркой "по дефолту" — не прокатило :(
>с PHP на что-то ещё.
Ну это от задач зависит, в первую очередь. Вот если вам дадут написать что-то типа IDE — сразу возникает вопрос, а на чем написан PHPStorm? :) А если попросят мобильное приложение — то логичным выбором становится что-то другое. А если компилятор — то третье.
Ну т.е. есть у языка своя ниша, это веб разработка, и именно в этой нише он нормально существует. И мне кажется вопрос выбора или смены инструмента всегда должен определяться задачами.
Ну это от задач зависит, в первую очередь. Вот если вам дадут написать что-то типа IDE — сразу возникает вопрос, а на чем написан PHPStorm? :) А если попросят мобильное приложение — то логичным выбором становится что-то другое. А если компилятор — то третье.
Ну т.е. есть у языка своя ниша, это веб разработка, и именно в этой нише он нормально существует. И мне кажется вопрос выбора или смены инструмента всегда должен определяться задачами.
Веб-разработка очень широкое понятие очень широкое сейчас, в эпоху когда HTTP lingua franca сервисов и микросервисов на разных ЯП, а очень многие задачи сводятся к, по большому счёту, принять http запрос, чисто преобразовать его в какой-то граф данных, сделать запрос к хранилищу, получить ответ в виде какого-то графа данных, преобразовать в http-ответ и отдать его клиенту.
А кто спорит? Несомненно, веба очень много (как самого по себе, так и бэкенда для мобильных приложений). Но другие области разработки тоже имеются, и они тоже сами по себе не мелкие.
Вот веб — не ниша PHP, у него там куча конкурентов.
Разумеется. Но я бы сказал что в областях, под которые язык изначально не создавался, вообще шансов мало. Так что остается таки веб, и все что около него. И лавировать между наличием продвинутых возможностей и простотой входа.
Ну и кстати, продвинутые возможности… Возьмем простой случай — подключение к базам данных. Казалось бы, везде есть. Но что в моем понимании энтерпрайз? Это когда к тебе приходят безопасники, и говорят — чтобы через полчаса в лесу было светло, сухо, и медведь (с), в смысле, чтобы завтра все коннекты к ораклу были шифрованные, потому что с завтрашнего дня наш энтерпрайз будет обрабатывать персональные данные… И если некий язык/платформа такого не умеет — они будут в пролете (для таких задач, конечно).
Ну и кстати, продвинутые возможности… Возьмем простой случай — подключение к базам данных. Казалось бы, везде есть. Но что в моем понимании энтерпрайз? Это когда к тебе приходят безопасники, и говорят — чтобы через полчаса в лесу было светло, сухо, и медведь (с), в смысле, чтобы завтра все коннекты к ораклу были шифрованные, потому что с завтрашнего дня наш энтерпрайз будет обрабатывать персональные данные… И если некий язык/платформа такого не умеет — они будут в пролете (для таких задач, конечно).
За оракл, мс или экзотику не скажу, но для мускуля или постгри под PHP ssl коннекты — вопрос пары-тройки опций обычно в клиентском коде или вообще строке подключения в env переменных или конфиге. Хотя могут быть нюансы, если безопасники хотят странного типа не верифцировать сертификат клиента в принципе. Или если используется минимальная сборка бинарников php — нужно будет добавить ключей компиляции.
Ну вот не так все просто. Для некоторых версий оракла в строке эти опции задать нельзя. У jdbc есть отдельное место, где задаются прочие параметры. Ну т.е. я не говорю, что у PHP этого скажем нет (я тут просто не в курсе), я скорее говорю, что вот такая вот «мелочь» может много чего решить в конкретном проекте.
Мне это ничего не говорит, но вам, может, скажет: "Это может быть » Easy Connect string, или Connect Name из файла tnsnames.ora, или имя локального экземпляра Oracle." — достаточно?
С другой стороны, слабо представляю как на одном проекте могут встретиться Oracle и PHP
Ну, если в проекте нет оракла — на мой взгляд это уже ненастоящий энтерпрайз :) Понятно, что может быть MS SQL, например, ну или даже greenplum, так что это скорее шутка.
Честно говоря, хз. В виде текста это выглядит как-то так:
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256,AES192,AES128)
SQLNET.ENCRYPTION_SERVER = accepted
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA1)
SQLNET.CRYPTO_CHECKSUM_SERVER = accepted
И для каких-то ораклов можно задать прямо в строке подключения, а для старых (типа 11-го) похоже что нельзя.
Я вообще вот совсем недавно с некоторым удивлением узнал, что oracle thin jdbc драйвер умеет прямо вот так:
«jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=somehost.us.example.com)(PORT=5561))» +"(CONNECT_DATA=(SERVICE_NAME=itydemo.regress.rdbms.dev.us.example.com)))";
и тут можно указывать всякие там fallback, кластера из нескольких машин, число повторов и т.п. Причем я много лет с ним работаю, а вот подиж, ни разу не попадалось. Видимо, предыдущие энтерпрайзы были не совсем энтерпрайзы :)
Честно говоря, хз. В виде текста это выглядит как-то так:
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256,AES192,AES128)
SQLNET.ENCRYPTION_SERVER = accepted
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA1)
SQLNET.CRYPTO_CHECKSUM_SERVER = accepted
И для каких-то ораклов можно задать прямо в строке подключения, а для старых (типа 11-го) похоже что нельзя.
Я вообще вот совсем недавно с некоторым удивлением узнал, что oracle thin jdbc драйвер умеет прямо вот так:
«jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=somehost.us.example.com)(PORT=5561))» +"(CONNECT_DATA=(SERVICE_NAME=itydemo.regress.rdbms.dev.us.example.com)))";
и тут можно указывать всякие там fallback, кластера из нескольких машин, число повторов и т.п. Причем я много лет с ним работаю, а вот подиж, ни разу не попадалось. Видимо, предыдущие энтерпрайзы были не совсем энтерпрайзы :)
Явно разные у нас понятия об ентерпрайзе :) Есть примеры известных в рунете компаний, которые "почти ентерпрайз", но не дотягивают по организационно-правовым и экономическим показателям, а не признаку использования Оракла? )
Понятия не имею, если честно. Я практически с 2005 года работаю практически только на банки, и по своему опыту могу сказать, что то что я там видел, выглядело примерно так: Oracle, Sybase+ Sybase IQ, Oracle, DB2, MS SQL, Greenplum, Oracle + MS SQL+ Терадата (примерно в том порядке, что я с ними работал). А все остальное — либо как вспомогательные (типа Hive MetaStore), либо прототипы. Ну т.е. в моем случае можно было найти PostgreSQL в прототипе, и я сам такой делал, но к выходу в пром это все равно был оракл. Почему так? В текущем проекте — потому что у них есть Golden Gate, и достойных альтернтатив ему не то чтобы очень много было видно на горизонте. А вторая причина видимо еще проще — если у вас есть купленные вендорские решения (типа Smartvista), то там у вендора просто написано — мы поддерживаем вот такие СУБД, например. Ну и кто будет рисковать карточными транзакциями, и пытаться ставить неподдерживаемую СУБД?
Ну, можем посмотреть с другой стороны. По вашему, что такое энтерпрайз? По-моему это много разных видов компаний.
Да, много, но некоторые признаки я бы выделил:
- жёсткие иерархии подчинения, ответственности и полномочий
- в целом формализованные процессы
- в частности бюрократия, планы, отчёты, бюджетирование
Ну, да. Где-то имеет место. Но я бы сказал, что мне это никогда не мешало. Они уж не настолько жесткие и формализованные, если у компании есть хоть какие-то реальные цели, типа зарабатывания денег, и если ты этих целей реально достигаешь.
Тут больше не про мешание я, наверное, а про минимальное влияние на продукты компании на рядовых позициях, даже на чисто технические вопросы типа обновление зависимости :)
Чтобы имеющая место бюрократия мешала в технических вопросах — я вообще никогда не видел. Ну т.е. да, вам могут сказать (и вполне резонно), что релиз приложения должен быть собран на CI сервере, из зависимостей, лежащих в корпоративном хранилище артефактов, а не взятых неизвестно где. Но это обычная гигиена процесса сборки, не более того.
Насчёт корпоративного хранилища спорно, имхо, ноя про то, что чтобы обновить зависимость с, условно, 7.3.7 на 7.3.9 нужно получить апрув от лида (ведущего инженера, простите), на 7.4.0 от от начальника депратамента, а на 8.0.0 от совета директоров.
>спорно, имхо
В интранете, где другого хранилища вообще нет? Не, ну вы можете конечно собрать из артефактов, коорые прислали себе по почте. В процессе разработки. Но идти с таким в пром, ну такое себе решение.
Если это не оракл (на который нужна лицензия) — то никогда не спрашивал такого апрува. Наоборот бывает — приходят безопасники, и говорят — у вас на Java 1.х закончился период поддержки, обновляйте. Все остальное — на свое усмотрение.
В интранете, где другого хранилища вообще нет? Не, ну вы можете конечно собрать из артефактов, коорые прислали себе по почте. В процессе разработки. Но идти с таким в пром, ну такое себе решение.
Если это не оракл (на который нужна лицензия) — то никогда не спрашивал такого апрува. Наоборот бывает — приходят безопасники, и говорят — у вас на Java 1.х закончился период поддержки, обновляйте. Все остальное — на свое усмотрение.
Там где нет, да, какое-то своё зеркало надо делать, но это очень жёсткие ограничения. Мне такие не попадались на практике, включая проекты в финансах и медицине. Только для ускорения сборки поднимал кэширующие прокси для пакетов, а так хосты вполне могут ходить наружу.
>жёсткие ограничения
На самом деле взлом чего-либо путем подмены хранилища артефактов для разных его типов — это уже настолько типовая фигня, что я затруднюсь пожалуй подсчитать, сколько раз я про такое читал.
Ну и кто вам во внешнем хранилище гарантирует повторяемость сборки? В своем мы заведомо можем запретить менять релизные версии, и это хорошая практика. А поднять условный nexus — это вообще дело 30 минут.
На самом деле взлом чего-либо путем подмены хранилища артефактов для разных его типов — это уже настолько типовая фигня, что я затруднюсь пожалуй подсчитать, сколько раз я про такое читал.
Ну и кто вам во внешнем хранилище гарантирует повторяемость сборки? В своем мы заведомо можем запретить менять релизные версии, и это хорошая практика. А поднять условный nexus — это вообще дело 30 минут.
Вот веб — не ниша PHP, у него там куча конкурентовЕсли бы в PHP добавили строгую типизацию, то конкурентов бы не было.
Ну как бы, если памяти у вас мало (а это скажем что-то embedded), то тем не менее существовала когда-то JavaME, которая работала на телефонах. И существует Андроид, где она тоже работает (не совсем такая же, но это уже не так важно). Т.е. эта проблема — она в принципе решаема, GC можно вообще убрать практически до нуля, как и аллокацию (правда, придется попотеть и подумать головой).
А если памяти у вас много, ну скажем как в моей области больших данных, где 256 гигабайт доступно на узел кластера практически везде, включая кластер разработки — то во многих случаях память и не нужно зря экономить — потому что простое кеширование того, что можно закешировать — это зачастую самый простой и дешевый способ оптимизировать время выполнения. Это не значит, что ее вообще не нужно экономить — это значит, что ее не нужно напрасно экономить, т.е. потратить лишние сотню гигабайт чтобы сократить время обработки с часа до 15 минут — часто это более чем разумный компромисс.
А если памяти у вас много, ну скажем как в моей области больших данных, где 256 гигабайт доступно на узел кластера практически везде, включая кластер разработки — то во многих случаях память и не нужно зря экономить — потому что простое кеширование того, что можно закешировать — это зачастую самый простой и дешевый способ оптимизировать время выполнения. Это не значит, что ее вообще не нужно экономить — это значит, что ее не нужно напрасно экономить, т.е. потратить лишние сотню гигабайт чтобы сократить время обработки с часа до 15 минут — часто это более чем разумный компромисс.
Ruby не в чистилище завис, вышла версия 3.0, которая на фоне PHP 8.0 смотрится великолепно, а на фоне Ruby 3.0, версия PHP 8.0 смотрится как застрявшая в чистилище :)
Я считаю, что PHP либо необходимо не добавлять фичи, а полностью переработать язык, кардинально, не таща всё и ото всюду, либо не тащить всё и ото всюду, а добавлять только необходимые фичи, а не «приколюхи», в ином случае энтерпрайз в конце концов откажется от PHP в пользу альтернатив
Я считаю, что PHP либо необходимо не добавлять фичи, а полностью переработать язык, кардинально, не таща всё и ото всюду, либо не тащить всё и ото всюду, а добавлять только необходимые фичи, а не «приколюхи», в ином случае энтерпрайз в конце концов откажется от PHP в пользу альтернатив
Думаю, PHP отлично сохранится как удачное средство прототипирования и быстрой разработки на стыке бэка и фронта. Эдакий веб-питон :)
Новые фичи 8-ки — это, скорее, возможности, чем обязаловка. К примеру, есть множество успешных проектов на PHP, вообще не использующих объектную парадигму, и написанных в стлие «пиэчпизма» образца 2000 года.
Новые фичи 8-ки — это, скорее, возможности, чем обязаловка. К примеру, есть множество успешных проектов на PHP, вообще не использующих объектную парадигму, и написанных в стлие «пиэчпизма» образца 2000 года.
быстрокодеров — норм так завуалировали
В последнее время все чаще на слуху что люди уходят с PHP на Go. Но с чего бы?
На гошке очень тяжело писать декларативно-понятный с первого взгляда код (одни проверки ошибок на каждый чих чего стоят). Неудобно сегрегировать бизнес-логику. Сложно проектировать по DDD (если вообще уместно). Он быстрый, современный, но скриптовый) В самый раз для микросервисов.
PHP все больше становится похож на Java, что делает его очень неплохим языком для написания сложных архитектур на бэке. Плюс он определенно «линдиустойчивый» (Н.Талеб «Шкура на кону»). Можно с высокой вероятностью сказать, что проживет еще столько же.
Оба языка стремительно развивиются и у каждого есть свои плюсы и минусы. Мое мнение — не будет монополиста. Думаю они оба займут свои ниши.
На гошке очень тяжело писать декларативно-понятный с первого взгляда код (одни проверки ошибок на каждый чих чего стоят). Неудобно сегрегировать бизнес-логику. Сложно проектировать по DDD (если вообще уместно). Он быстрый, современный, но скриптовый) В самый раз для микросервисов.
PHP все больше становится похож на Java, что делает его очень неплохим языком для написания сложных архитектур на бэке. Плюс он определенно «линдиустойчивый» (Н.Талеб «Шкура на кону»). Можно с высокой вероятностью сказать, что проживет еще столько же.
Оба языка стремительно развивиются и у каждого есть свои плюсы и минусы. Мое мнение — не будет монополиста. Думаю они оба займут свои ниши.
зачем в таком случае нужна “вторая” джава, если уже есть первая?Вы ответили это в самом начале — очень легко найти сотрудника, и за очень дешево. Корпорации тоже любят считать деньги, и они с радостью возьмут разработчика PHP, если он будет способен сделать тоже самое, что и Java-разработчик, но за меньшие деньги.
Далее, про скорость разработки. Чаще всего она выше у PHP, а это значит, корпорации затратят ещё меньше ресурсов на получение результата. Цифр у меня нет, поэтому пусть это останется лишь моим наблюдением.
Касательно энтерпрайзного Java — да, она сейчас #1, и будет в топе ещё долго. И php совсем не скоро даже догонит его. Но причина почему — так и не была озвучена. А она проста — Легаси. Уже написано слишком много софта на Java, который нужно дальше поддерживать и развивать. И эти системы чертовски сложные и запутанные. Добавляем к этому изначальную сложность Java (по сравнению с PHP), и получаем дорогого разработчика, который готов разбираться во всём этом, потому-что ему платят достаточно для копания.
Вторая причина, почему Java чаще выбирают в мире энтерпрайз — опять же поставщики софта и оборудования (ibm, привет!) часто присылают примеры кода и пакеты для интеграций только на Java/Net, и не готовы что-то там докодить на PHP, и по сути не заявляют о поддержках PHP для интеграций. А так-как поставщики не разрешают (не суппортят) интегрироваться на других языках — то ИТ-директор выбирает то, что поставщик точно будет суппортить. Вот и всё, круг замкнулся.
При этом, как было верно отмечено, сейчас Java умеет слишком многое, до чего PHP либо никогда не дотянется (железо), либо придет не скоро. Но когда нужно сделать что-то не слишком сложное — PHP очень даже годится, и вырывает свой сегмент своими
Можете ругать сколько угодно PHP. И не важно на каком он месте.
Я благодарен этому языку, так как он 10 лет был основным инструментом и был моим «кормильцем».
Я благодарен этому языку, так как он 10 лет был основным инструментом и был моим «кормильцем».
в погоне за тем, чтобы стать «правильным», PHP легко может потерять свою простоту и скорость разработкиПока что это утверждение спорное. «Наколенный» код, который я писал лет 20 назад для пет-проектов во времена PHP 4, до сих пор без проблем крутится теперь уже на PHP 8 без существенных переделок (не считая разве что миграции с расширения mysql на PDO примерно во время выхода PHP 5.4, ну и мелкие правки вроде неправильного порядка аргументов в implode, который раньше разрешал менять их местами). Так что теперь есть два способа писать на PHP — быстро но костыльно и медленно но качественно. Новые фичи не ломают старые, а признанные устаревшими убираются не сразу, а сперва на пару мажорных версий помечаются, как устаревшие, давая разработчикам несколько лет на то, чтобы отловить в логах предупреждения и пофиксить.
Вопрос по КДПВ. Зачем указывать
@var boolean перед константой?
Вот только очень быстро стремиться к первому месту, если уже его не занял, язык с не меньшим грузом накопленных проблем чем у ПХП, так что может, не только (столько) в языке дело.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ловушки для современного PHP