Комментарии 344
PHP-разработчиков постоянно унижать, они будут покидать сообщество, и в нем будет оставаться все меньше хороших PHP-программистов.
Как говорит Жорес Алферов — тут остались одни оптимисты, потому что пессимисты уехали.
НЛО прилетело и опубликовало эту надпись здесь
Это вам видимо везло. У меня периодически проскакивают клиенты, которым «знакомые разработчики» сказали, что всё, что написано на PHP — говно, и поэтому они против PHP в качестве основного языка проекта
У PHP низкий порог входа. Очень много новичков посмотревших в документации пример работы с MySQL начинают программировать, но качество их работы очень низкое, порой их код нечитаем (быдлокод). Наверное в этом и причина негативного отношения к PHP — на нем можно писать некачественный код и он будет работать.
на нем можно писать некачественный код и он будет работать.
Это самая сильная сторона PHP (минимум усилий вплодь до деплоя что бы получить что-то работающее), она же является его бедой, но далеко не все застревают где-то на уровне wordpress.
Вы знаете, сейчас на любой мало-мальски распространенной платформе можно писать некачественный код, и он будет работать. Это тренд, а не исключение.
В сложном языке программирования работает естественный отбор, на той же Java недоучка не сможет ничего сделать
Да ладно, Java разная бывает. Не забывайте про андроид. Гугл вложил кучу усилий для того что бы любой человек мог написать свое приложение под андроид.
Да ладно, по программе института, прохожу уравнительный семестр Java с 1 годками, смотря исполнения некоторых лаб могу сказать, можно писать и там не читаемый код.
Да ладно, как раз с тех пор, как появился VB, потом Java и вслед за ними прочие языки четвертого поколения, которые сделали возможным программирование без управления памятью, необходимая планка квалификации, чтобы написать «шоб хоть как-то работало», значительно упала.
Статья целиком состоит из нытья по поводу того, что к PHP относятся как-то не так, как хотел бы автор.
«Всё очень плохо, и нужно лучше, а вот не получается, и что делать я не знаю».
Вместо написания статьи имело бы больше смысла молча принять к сведению все преимущества\недостатки и использовать эти знания при выборе инструментария для конкретного проекта.
«Всё очень плохо, и нужно лучше, а вот не получается, и что делать я не знаю».
Вместо написания статьи имело бы больше смысла молча принять к сведению все преимущества\недостатки и использовать эти знания при выборе инструментария для конкретного проекта.
Да пусть разработчики на «настоящих» языках и дальше снобствуют, нам-то что с того? Наоборот, приятно наблюдать, когда эти мегаджедаи явы и асп обсираются и срывают проект, который пилили по 2-3 года, а ребята на PHP переписывают его за полгода, с значительно меньшими издержками. Ну да, за то «У НАС ЖЫ ЫНТЫРПРАЙЗ!»
Ну к примеру Python явно не ЫНТЫРПРАЙЗ, но на нём можно писать ещё быстрее чем на PHP (банально строк меньше выходит :) ). Это я к тому, что с java/C# не только PHP сражается но и Python,Ruby,JavaScript и теперь Go.
А Ruby разве ещё жив?
Python? А что для веба на нём вообще написано? ИМХО, как язык скриптов и десктоп приложений он очень и очень хорош, но в вебе он как РНР в десктоп ПО.
JavaScript — согласен, нода очень и очень хорошо выстрелила, с интересом смотрю на неё. Как и на Go.
Python? А что для веба на нём вообще написано? ИМХО, как язык скриптов и десктоп приложений он очень и очень хорош, но в вебе он как РНР в десктоп ПО.
JavaScript — согласен, нода очень и очень хорошо выстрелила, с интересом смотрю на неё. Как и на Go.
насчёт python вы сильно ошибаетесь, django, flask посмотрите для старта
Я знаю про них, но что на них особо пишут? Какие известные проекты? Даже на Ruby я могу вспомнить GitHub, а на Python ничего в голову не приходит из такого же уровня.
Instagram, Disqus и Pinterest — на Django
Спасибо за ответы, признаю, был неправ про Python.
Disqus на Go теперь.
Go — всё-таки немного другая ниша. Это скорее язык на который переписывают проекты, когда им становится тесно в лимитах интерпретируемых языков, а не на котором начинают новое (если ты не гугл).
Не согласен. По мне, Go сейчас прямой конкурент PHP, Питону и Ноде на бэкенде.
Он простой, быстрый, компилируемый и имеет отличную поддержку конкаренси из коробки.
Конечно, по распространенности он не может сейчас бороться с вышеперечисленными языками, но за последний год растет очень быстро.
Он простой, быстрый, компилируемый и имеет отличную поддержку конкаренси из коробки.
Конечно, по распространенности он не может сейчас бороться с вышеперечисленными языками, но за последний год растет очень быстро.
Reddit, Dropbox, Yelp, Quora и многие други.
Dropbox на Go переходит.
Ну им теперь тесно, переходят же то не потому что Python это плохо. Далеко не у каждого проекта будут такие проблемы.
Странно что не на Scala, у них же хороший евангелист там есть — Li Haoyi. Продуктивности этого чувака может позавидовать любой разраб… Хотя учитывая то, насколько Go активно пиарится и что он в разы проще, не удивительно что выбор пал именно на него.
bitbucket например ;)
дело даже не в этом, Вы просто очень категорично к python отнеслись
мне как PHP-разработчику очень интересно работать с python/django, там есть чему поучится и что можно было бы применить/уже применяется в PHP мире
к примеру, тот же Symfony вдохновлён как Spring, так и Django, и Rails
дело даже не в этом, Вы просто очень категорично к python отнеслись
мне как PHP-разработчику очень интересно работать с python/django, там есть чему поучится и что можно было бы применить/уже применяется в PHP мире
к примеру, тот же Symfony вдохновлён как Spring, так и Django, и Rails
От спринга в симфонии архитектура и похожий на гибернейт ORM, от джанго — похожий шаблонизатор. А что в Symfony от Rails? Всегда считал, что воплощение рельс на РНР — Yii.
Yii 1.0 был воплощением рельс. 1.1 уже был прилично не похож. 2.0 унаследовал разве что философию.
Symfony года на 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.
Я Flask распробовал — мне он даже больше Dajango понравился. Если не нужна джанговская админка — самое оно. А если надо event-driven, то Twisted.
Если нужна «джанговская» админка – есть flask-admin. К тому же, моя практика показывает, что именно джанговская админка с реальными задачами справляется не очень хорошо.
Мне вот во Flask дико не хватает вменяемого RBAC :( У джанги он из коробки, и прям отлично работающий я бы даже сказал.
Мой опыт говорит совершенно об обратной ситуации.
В данный момент в компании идет десяток проектов с привлечением внешних исполнителей. Внешние исполнители как интегрируют свои продукты, так и разрабатывают проекты с «нуля».
— Крупный и известный исполнитель со своим продуктом, сроки пролетели уже в несколько раз. Свой продукт на 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#, правилами, паттернами, кодревью, оптимизацией, сетью и БОЛЬШОЙ ОТВЕТСТВЕННОСТЬЮ за написанный софт.
В данный момент в компании идет десяток проектов с привлечением внешних исполнителей. Внешние исполнители как интегрируют свои продукты, так и разрабатывают проекты с «нуля».
— Крупный и известный исполнитель со своим продуктом, сроки пролетели уже в несколько раз. Свой продукт на 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#, правилами, паттернами, кодревью, оптимизацией, сетью и БОЛЬШОЙ ОТВЕТСТВЕННОСТЬЮ за написанный софт.
Поддерживаю. Мой опыт говорит о том же. Я не сомневаюсь, что есть хорошие программисты на PHP, которые следуют стандартам, паттернам и прочим «ЫНЫТЫРПРАЙЗ» штучкам, но та реальность с которой сталкиваешься каждый раз уныла, чуть более чем совсем.
Я не следую «ЫНЫТЫРПРАЙЗ» штучкам (за исключением редких ситуаций, когда реально надо), но проекты сдаю вовремя и оттестированными. Что я делаю не так? :)
Я про то и пишу — таких как Вы, меньшинство, к сожалению. Я в своей практике очень редко встречался с грамотными PHP-шниками.
Ох, извиняюсь, прочитал неправильно, на заметил «не» :)
Мое мнение, что каждой задаче — свой инструмент. Это касается и языков и паттернов и методологий. Если нужно забабахать страничку в вебе или интернет-магазин, то почему бы не использовать PHP (даже без ООП, обожемой, что я говорю!), если он Вам по душе. Но все-таки на серьезные проекты, где требуется жесткий контроль за качеством выходного продукта, лучше взять тех же джавистов, чем пхпшников, имхо. Так сложился рынок…
Хотя опять же оговорюсь, если у Вас команда толковых PHP-шников, в которых Вы уверены, то почему бы и не использовать их :) Я вот таких не встречал, о чем написал выше.
Мое мнение, что каждой задаче — свой инструмент. Это касается и языков и паттернов и методологий. Если нужно забабахать страничку в вебе или интернет-магазин, то почему бы не использовать PHP (даже без ООП, обожемой, что я говорю!), если он Вам по душе. Но все-таки на серьезные проекты, где требуется жесткий контроль за качеством выходного продукта, лучше взять тех же джавистов, чем пхпшников, имхо. Так сложился рынок…
Хотя опять же оговорюсь, если у Вас команда толковых PHP-шников, в которых Вы уверены, то почему бы и не использовать их :) Я вот таких не встречал, о чем написал выше.
Я пять лет писал веб на J2EE. Это ужасно (по крайней мере было) по сравнению с PHP. Мордочки больших Java-проектов и то пишут на PHP потому что развивать их так проще: деплой проще, отлаживать проще, из коробки больше всего. С нормальных фреймворком даже на косяки PHP не наступаешь. Вообще красота!
Контроль не зависит от языка. Тут либо самодисциплина, либо грамотный управленец. Раздолбаев на Java не меньше, просто они лучше шифруются за ЫНЫТЫРПРАЙЗ-ом и паттернами.
Контроль не зависит от языка. Тут либо самодисциплина, либо грамотный управленец. Раздолбаев на Java не меньше, просто они лучше шифруются за ЫНЫТЫРПРАЙЗ-ом и паттернами.
Ваша правда, если мы уж затронули тему веб мордочек, то джава тут явно не на первом месте :)
А вот по контролю не соглашусь. PHP тут скорее исключение и именно из-за сложившейся конъюнктуры. В подавляющем большинстве PHP-программисты менее квалифицированы, чем Java-программисты. Сужу по людям и конторам, где работал, хотя понимаю, что мне могло тупо не везти :)
А вот по контролю не соглашусь. PHP тут скорее исключение и именно из-за сложившейся конъюнктуры. В подавляющем большинстве PHP-программисты менее квалифицированы, чем Java-программисты. Сужу по людям и конторам, где работал, хотя понимаю, что мне могло тупо не везти :)
Ваша правда, если мы уж затронули тему веб мордочек, то джава тут явно не на первом месте :)
У джавы тут все великолепно. Но часто получается так, что веб пилят те же программисты, что и всё остальное. У них громадный опыт программирования в их области и практически никакого в веб. Результат — соответствующий.
Мне интересно, вы действительно не знаете про velocity, freemarker, thymeleaf и прочие шаблонизаторы? Которые для той самой джавы и созданы (+ некоторые портированы с других игроков, например handlebars), И как раз, чтобы бекэндщикам не приходилось гнать говённый UI (который они всё равно не умеют готовить).
Контроль не зависит от языка. Тут либо самодисциплина, либо грамотный управленец. Раздолбаев на Java не меньше, просто они лучше шифруются за ЫНЫТЫРПРАЙЗ-ом и паттернами.
Вот поддержу. Просто и управленцам (им легче контролировать), и разработчикам (им легче скрывать косяки) повезло, что эталонная реализация Java — компилятор, что Java — язык с сильной статической типизации и, как следствие обоих пунктов, некоторые классы ошибок просто не могут попасть в исполняемый файл. Собственно не только Java касается, но и всех сильнотипизированных компилируемых языков — на них невозможно создать исполняемый файл с ошибками типизации и просто грубыми синтаксическими ошибками.
Если бы обычная практика разработки на компилируемых языках не включала обязательный статический анализ, то вряд ли что-то сильно бы отличалось от того же PHP, лучшие практики разработки на котором мало отличаются от практик той же Java. Включая статический анализ кода перед не то, что деплоем или коммитом, а даже запуском, в который (анализ) входит в том числе и проверка явного объявления переменных и типов (PhpDoc), и проверка на использование неявного приведения типов.
Мое мнение, что каждой задаче — свой инструмент. Это касается и языков и паттернов и методологий. Если нужно забабахать страничку в вебе или интернет-магазин, то почему бы не использовать PHP (даже без ООП, обожемой, что я говорю!), если он Вам по душе. Но все-таки на серьезные проекты, где требуется жесткий контроль за качеством выходного продукта, лучше взять тех же джавистов, чем пхпшников, имхо. Так сложился рынок…
Вот в этом и проблема основная — PHP разрабы пытаются все написать на нем…
и в чем тут проблема? я думаю если бы средний php разработчик просто так взял java/scala то все бы пошло куда более плохо.
А то что php разработчики используют для решения задач язык который они хорошо знают, то проблемы нет. Другое дело что большинство свой язык не очень хорошо знают.
А то что php разработчики используют для решения задач язык который они хорошо знают, то проблемы нет. Другое дело что большинство свой язык не очень хорошо знают.
Такому среднему типичному PHP разработчику бы пришлось разобраться со статической типизацией, нормально начать использовать эксепшены и разобраться с ООП. Так что спорно. Весь этот набор необходимых сопутствующих знаний прокачал бы его.
Весь этот набор необходимых сопутствующих знаний прокачал бы его.
Для всего этого не надо менять язык или пытаться пописать на Java (хотя это очень полезный опыт, вопробовать пописать еще на парочке языков).
Более того, вероятность того что человек разберется с ООП и т.д. только потому что возьмет java примерно такая же как и с PHP (я знаю достаточно java разработчиков которые понятия не имеют о SOLID или о том как работать с исключениями, а java 1.8 вообще позволяет в этом плане не особо заморачиваться).
Тут проблема в том что люди не знают что учить (хотя как мне кажется просто не хотят).
функционала на 4 страницы
Стоимость каждого из проектов, примерно, как квартира в Москве.
Немного странно, не находите?
Да там небось обычная ситуация, «а ну давай те вон тех наймем на пхп, они занедорого напишут».
А далее парят мозг, каждый день что-то заставляя менять, либо внезапно окажется, что проблема вообще не в пхп, а в том что кто-то не сказал, что верстка под мобильные устройства, например нужна.
Ну да так повелость, что парни на с# — java обычно и берут сильно больше и договор грамотно составляют, так что бы потом на просьбу «поиграться со шрифтами» выставить нифиговый счет.
Только это не проблема в языке, это проблема в мозгу всех причастных.
А далее парят мозг, каждый день что-то заставляя менять, либо внезапно окажется, что проблема вообще не в пхп, а в том что кто-то не сказал, что верстка под мобильные устройства, например нужна.
Ну да так повелость, что парни на с# — java обычно и берут сильно больше и договор грамотно составляют, так что бы потом на просьбу «поиграться со шрифтами» выставить нифиговый счет.
Только это не проблема в языке, это проблема в мозгу всех причастных.
С чего вы решили?
В ЫНТЫРПРАЙЗЕ так принято. 100500 совещаний менеджерья всех уровней, и за неделю до дедлайна дают Васе, который эти 4 странички напишет и получит свои скромные 50тыр/мес. А квартира разойдется по этим милым и прекрасным эффективным менеджерам.
С людьми вам не везёт. Ни язык ни фреймворк тут не при чём.
Писал большой развернутый коммент, но, к сожалению, не ушел :(
Если кратко:
По первой части: дебилы есть везде, это не аргумент. У вас свой опыт, у меня свой. Я чаще встречал идиотов, которые ради трехстраничного магазинчика с криком «ОЛОЛО, ЫНТЫРПРАЙЗ» брали J2EE/Spring/ещё-какое-то-страшное-говно и весело залипали на полгода-год. Очень частая и грустная история.
Offtop: ПО для терминала на РНР? ЛОЛШТО? Как? Зачем? Почему? Они бы ещё, ***, микроконтроллер на РНР программировали! При всей моей необузданной любви к РНР, он — только для веба и смежного (ну сервисные скрипты/демоны для этого проекта)
По второй части, как это коррелирует с языком? Неужели язык запрещает продумывать архитектуру, методологии? Неужели язык заставляет делать «оп оп и в прод»? А взяв какой-нибудь богомданный C#/Java программист тут же превращается в крутого синьёра, который пишет код, взглянув на который Дейкстра и Кнутт в обнимку будут плакать от умиления?
В последней части вы подставились. Вы всерьез думаете, что за 10 лет ничего не изменилось и мы всё так же барахтаемся в своём болоте? Для справки за последние 10 лет мир РНР изменился до неузнаваемости: появились нормальные стандарты кодирования, отличные инструменты, фреймворки, способные дать под зад этим разным спрингам.
Вроде ничего особо не забыл.
Если кратко:
По первой части: дебилы есть везде, это не аргумент. У вас свой опыт, у меня свой. Я чаще встречал идиотов, которые ради трехстраничного магазинчика с криком «ОЛОЛО, ЫНТЫРПРАЙЗ» брали J2EE/Spring/ещё-какое-то-страшное-говно и весело залипали на полгода-год. Очень частая и грустная история.
Offtop: ПО для терминала на РНР? ЛОЛШТО? Как? Зачем? Почему? Они бы ещё, ***, микроконтроллер на РНР программировали! При всей моей необузданной любви к РНР, он — только для веба и смежного (ну сервисные скрипты/демоны для этого проекта)
По второй части, как это коррелирует с языком? Неужели язык запрещает продумывать архитектуру, методологии? Неужели язык заставляет делать «оп оп и в прод»? А взяв какой-нибудь богомданный C#/Java программист тут же превращается в крутого синьёра, который пишет код, взглянув на который Дейкстра и Кнутт в обнимку будут плакать от умиления?
В последней части вы подставились. Вы всерьез думаете, что за 10 лет ничего не изменилось и мы всё так же барахтаемся в своём болоте? Для справки за последние 10 лет мир РНР изменился до неузнаваемости: появились нормальные стандарты кодирования, отличные инструменты, фреймворки, способные дать под зад этим разным спрингам.
Вроде ничего особо не забыл.
Я написал про опыт, свой опыт, он говорит обратное к
Я считаю, что скрипткиддис от PHP может спокойно и долго работать, а программисту от «энтерпрайза» не дадут второго-третьего шанса. Там рулит бабло.
Я за то, чтобы бить гвозди молотком, а не микроскопом. У PHP свой мир, где лучше него нет, а у C#/Java, свой мир. И я пишу о том, что каждый инструмент хорош для того, для чего его создавали. Я понимаю, можно и большие решения на GUI под окошки писать на JS. Но, зачем?
когда эти мегаджедаи явы и асп обсираются и срывают проект, который пилили по 2-3 года, а ребята на PHP переписывают его за полгода,
А взяв какой-нибудь богомданный C#/Java программист тут же превращается в крутого синьёра, который пишет код, взглянув на который Дейкстра и Кнутт в обнимку будут плакать от умиления?
Я считаю, что скрипткиддис от PHP может спокойно и долго работать, а программисту от «энтерпрайза» не дадут второго-третьего шанса. Там рулит бабло.
В последней части вы подставились. Вы всерьез думаете, что за 10 лет ничего не изменилось и мы всё так же барахтаемся в своём болоте? Для справки за последние 10 лет мир РНР изменился до неузнаваемости
Я за то, чтобы бить гвозди молотком, а не микроскопом. У PHP свой мир, где лучше него нет, а у C#/Java, свой мир. И я пишу о том, что каждый инструмент хорош для того, для чего его создавали. Я понимаю, можно и большие решения на GUI под окошки писать на JS. Но, зачем?
Дык я же согласился, что опыт у всех разный, у меня свой, у вас обратный. Тем не менее, и тот и тот есть в реальности.
Эм, откуда там вообще тогда есть программисты, если там такая Спарта? Неужели там только эльфы, которые не совершают (и не совершали никогда) ошибок от слова «совсем»? Выходит, так. Или где-то меня пытаются обмануть ;)
Именно, шулай! И этот мир — веб разработка. Я тоже за то, чтобы РНР из этого мирка никуда не перелезал. Но и за то, чтобы в этот мирок не лезло отребье из других областей.
Я считаю, что скрипткиддис от PHP может спокойно и долго работать, а программисту от «энтерпрайза» не дадут второго-третьего шанса. Там рулит бабло.
Эм, откуда там вообще тогда есть программисты, если там такая Спарта? Неужели там только эльфы, которые не совершают (и не совершали никогда) ошибок от слова «совсем»? Выходит, так. Или где-то меня пытаются обмануть ;)
У PHP свой мир, где лучше него нет
Именно, шулай! И этот мир — веб разработка. Я тоже за то, чтобы РНР из этого мирка никуда не перелезал. Но и за то, чтобы в этот мирок не лезло отребье из других областей.
НЛО прилетело и опубликовало эту надпись здесь
Вам ещё раз дать список проектов, сделанных на PHP, и зарплаты в этих проектах?
НЛО прилетело и опубликовало эту надпись здесь
spotify.com is powered by the @symfony framework and many great packages from http://packagist.org using Composer by @seldaek
Странные ребята, и rails уже был, и django, а эти дурни опять полезли в этот пыхапе!11
Странные ребята, и rails уже был, и django, а эти дурни опять полезли в этот пыхапе!11
2gis, wikimart, Innova, Alawar, flamp, runet-id, Etsy, mailchimp… можно вечно продолжать. О, ещё хабр, кстати ;)
blog.mailchimp.com/ewww-you-use-php
blog.mailchimp.com/ewww-you-use-php
Вы так говорите, как будто у тех же 2gis сам продукт написан на PHP. Вы хотя бы, прежде чем людей вводить в заблуждение, посмотрели хотя бы вакансии этих фирм, а если уж совсем не лениво то блоги их почитали бы. Там от всего что написано, на PHP поди одна страничка, а не окрепшие умы будут думать, что Innova Линейку на PHP написала(хотя они вообще лишь локализаторы) :-D
Ну да, у 2gis API на PHP и Yii. Я у команды был в офисе в Новосибирске, всё видел собственными глазами. Вы же не думаете, что я утверждаю, что у них приложение для iOS на PHP написано? :)
У Innova весь веб на PHP и Yii. Линейка, естественно, нет :)
У Innova весь веб на PHP и Yii. Линейка, естественно, нет :)
Да в курсе про, то что у них API и контент для юзеров PHP отдает. Но не зря же у них постоянно вакансии C++/Java разрабов в интернетах висят. Плюс ко всему на глаза попадалась часто фразы в духе «2Gis, scala developer».
Вообще такой подход многих фирм — это достаточно логичный выбор. Они понимают, что им нужно N количество девелоперов чтобы сделать отдачу контента например, и знаю что лучше взять язык X, даже не по соображениям продуктивности, а по соображениям где они будут брать этих самых девелоперов.
Вообще такой подход многих фирм — это достаточно логичный выбор. Они понимают, что им нужно N количество девелоперов чтобы сделать отдачу контента например, и знаю что лучше взять язык X, даже не по соображениям продуктивности, а по соображениям где они будут брать этих самых девелоперов.
Они же занимаются не только отдачей готовых данных. Все эти данные они ещё и собирают. Огромный штат картографов и контентщиков (не знаю, как правильно назвать тех, кто уточняет данные по фирмам). Надо тучу утилит, чтобы всё это приятно вбивать и обрабатывать. Ну и, скорее всего, тяжёлую обработку они делают сейчас не на PHP. Это нормально.
Хабр это был первый проект Денискина, другие вот проекты уже делали на рельсах.
habrahabr.ru/company/xakep/blog/203094/#comment_7028358
Хабр на PHP, на RoR brainstorage.me, hantim.ru, freelansim.ru и autokadabra.ru.
Toster.ru тоже на PHP.
habrahabr.ru/company/xakep/blog/203094/#comment_7028358
Какая смешная получается статья. Такое себе оправдание, аля «да, мы смогли сделать нормальный продукт на PHP». Не, ну хорошо, если руки ровные, только как это все добавляет плюсиков самому PHP, я не понимаю.
Поподробнее расскажите про серьезные вещи
НЛО прилетело и опубликовало эту надпись здесь
Flickr вроде всегда был на PHP: highscalability.com/flickr-architecture
НЛО прилетело и опубликовало эту надпись здесь
Никто не спорит, что питон был очень популярен когда Django был трендовым. Такое случалось со всеми платформами и не удивительно, что есть написанные практически на любой нормальной платформе отличные проекты.
а почему именно был?
Потому что сейчас он не трендовый, а просто отличный и самый крупный фреймворк на питоне. То же с RoR. Во времена «блога за 15 минут» на рельсы бежали все сломя голову. Потом мода прошла, люди поняли, что рельсы код за них писать не будут и успокоились. Рельсы стали просто замечательным руби-фреймворком, но сломя голову на них бежать перестали.
Сейчас в тренде нода, хотя уже самый пик спадает.
Сейчас в тренде нода, хотя уже самый пик спадает.
Почему мы должны смиряться? Потому что какой-то странный человек так сказал? Ха-ха-ха. Нет уж, с вашего позволения, продолжу делать прекрасные большие проекты на PHP/Symfony 2.
Offtop: ПО для терминала на РНР? ЛОЛШТО? Как? Зачем? Почему?
Что такое современный терминал знаете? Обычная персоналка с купюроприемником и сенсорным экраном. Для его задач ресурсов более чем достаточно, чтобы поднять обычную десктопную ось, запустить в ней браузер и какой-нибудь веб-серверный стэк (включая даже «взрослую» БД) в практически однопользовательском режиме. Почему не «LAMP»? Работа с купюропреемником (через либы вендора) инкапсулируется в расширении PHP, или отдельном относительно тупом сервере на, например, питоне и большинство задач по интерфейсу может решать обычный «сайтостроитель».
Знаю, даже делал оболочку к нему (но не на РНР). Вопрос остаётся. Разве не проще взять какой-нибудь nw.js в kiosk-mode (и да, к купюроприёмнику там интерфейс есть через расширение node.js). Или, о ужас, написать нативную десктоп приложуху на практически чём угодно.
Любой, даже самый двинутый «сайтостроитель» может в js, так что вариант с nw.js вполне может взлететь. Да даже есть всякие извращения типа для созданий «нативных» приложений на РНР, для самых упоротых.
Вот только зачем там веб-фреймворк то? Не вижу ни одной объективной причины.
Любой, даже самый двинутый «сайтостроитель» может в js, так что вариант с nw.js вполне может взлететь. Да даже есть всякие извращения типа для созданий «нативных» приложений на РНР, для самых упоротых.
Вот только зачем там веб-фреймворк то? Не вижу ни одной объективной причины.
Кому проще, а кому нет. Сроки, опять же. Ещё есть такое слово «унификация». Как правило, у компании есть сайт, где можно провести те же операции, что и в терминале только вместо кэша карты и электронные деньги — писать два раза одну логику? Или и сайт делать на node.js? Не вижу ни одной объективной причины писать сайт платежной системы на node.js. А обёртку купюроприемника вполне может быть на чём угодно, включая node.js. А внутренний сервер логично писать на веб-фреймворке, коль скоро принято решение, что интерфейс будет в браузере. Какой фреймворк на каком языке — это уже ситуационные решения.
Проекты в конечном итоге делают не инструменты, их делают люди. Одна команда делает на технологическом стеке «А» быстро и качественно, а другая на стеке «Б» делает кое-как. А третья и «А» не умеет готовить… Так было и есть. И веротяно еще не изменится какое-то время.
У меня есть другой опыт. Был серьезный проект для очень крупной компании. Поскольку «php-ники ж не шибко умные, не серьезно все это» взяли джависта. Что такое юнит тестирование — не знаем. Зачем нужно писать тесты — не знаем. SOLID — что это, зачем это все надо.
Сам по себе проект простой — если упрощать что-то типа сервиса заявок, кто успел того и заявка. Работать все это должно было в условиях плохой сети так что конфликты возникают часто.
Итог — срыв сроков, постоянные регрессии, при синхронизации и возникновении конфликтов происходят баги которые разработчик не мог пофиксить больше месяца. Ну и опять же когда фиксил что-то одно ломалось что-то другое. Дошло до того что посадили рядом php разработчика который хотя бы функциональными тестами это дело покрыл.
p.s. Я лично за 6 лет ни разу не видел адекватно написанного проекта на Yii. Как-то так сложилось (сам 3 года работал с ним и знаю его хорошо, сам ходил по всем возможным граблям), что проекты как только приобретали определенную сложность (что-то сложнее CRUD-а, например интернет магазин со специфичной бизнес логикой или биржа труда) разработчики сразу же превращали код в мессиво (и сам таким грешил, ибо фреймворк сам по себе потворствовал этому).
Я хорошо помню один комментарий в ишус трекере Yii (увы не дословно) при обсуждении добавления IoC или контейнера зависимостей: We don't need some fancy patterns. Он очень хорошо передает суть.
А вот это уже проигрыш сразу. Если разработчик собирается использовать решение которое поддерживать может только он то от него надо бежать.
Сам по себе проект простой — если упрощать что-то типа сервиса заявок, кто успел того и заявка. Работать все это должно было в условиях плохой сети так что конфликты возникают часто.
Итог — срыв сроков, постоянные регрессии, при синхронизации и возникновении конфликтов происходят баги которые разработчик не мог пофиксить больше месяца. Ну и опять же когда фиксил что-то одно ломалось что-то другое. Дошло до того что посадили рядом php разработчика который хотя бы функциональными тестами это дело покрыл.
p.s. Я лично за 6 лет ни разу не видел адекватно написанного проекта на Yii. Как-то так сложилось (сам 3 года работал с ним и знаю его хорошо, сам ходил по всем возможным граблям), что проекты как только приобретали определенную сложность (что-то сложнее CRUD-а, например интернет магазин со специфичной бизнес логикой или биржа труда) разработчики сразу же превращали код в мессиво (и сам таким грешил, ибо фреймворк сам по себе потворствовал этому).
Я хорошо помню один комментарий в ишус трекере Yii (увы не дословно) при обсуждении добавления IoC или контейнера зависимостей: We don't need some fancy patterns. Он очень хорошо передает суть.
исполнитель со своим продуктом на PHP
А вот это уже проигрыш сразу. Если разработчик собирается использовать решение которое поддерживать может только он то от него надо бежать.
Т.е. вы, сами не обладая экспертизой в Java за каким-то «надом» наняли отдельного java-программиста (о навыках которого не могли судить)? И это «серьёзный проект»? Да с тем же успехом вы могли фрилансера нанять! Никаких гарантий, если нет опыта работы с конкретным человеком. В целом же — самостоятельный проект требует квалификации близкой к сениору — у большинства мидлов просто не хватит опыта, чтобы во всех узких местах пролезть.
Т.е. вы, сами не обладая экспертизой в Java за каким-то «надом» наняли отдельного java-программиста
Так не я же лично, так решило начальство. Как проходил найм я могу только догадываться. Да и прособеседовать Java разработчика я например могу, но меня к этому вопросу привлекли уже когда все пошло не так.
Никаких гарантий, если нет опыта работы с конкретным человеком.
Есть еще проекты различной сложности. Скажем вы могли успешно сотрудничать с человеком в рамках простых проектов, а чуть сложнее и начинется веселье.
Fesor Не сочтите за рекламу. Вот часть проектов над которыми мне пришлось работать. В основном это ERP системы и им подобные. Все написаны на Yii: часть на первой версии, часть на второй. Ни разу не испытывал проблем с архитектурой.
Да, у фреймворка есть архитектурные проблемы (особенно у первой версии, у второй почти все нормально). Но они никак не мешают строить грамотную архитектуру своего кода.
И сейчас новые пректы я пишу именно на нем т.к. этот фреймвокр, на мой взгляд, предоставляет наилучшее соотношение возможностей и простоты. В нем все очень хорошо и «правильно», но без фанатизма.
Для справедливости отмечу, что я не использую его для генерации html сайтов (разрабатываю только rest api) и про эту часть фреймворка сказать ничего не могу.я
Да, у фреймворка есть архитектурные проблемы (особенно у первой версии, у второй почти все нормально). Но они никак не мешают строить грамотную архитектуру своего кода.
И сейчас новые пректы я пишу именно на нем т.к. этот фреймвокр, на мой взгляд, предоставляет наилучшее соотношение возможностей и простоты. В нем все очень хорошо и «правильно», но без фанатизма.
Для справедливости отмечу, что я не использую его для генерации html сайтов (разрабатываю только rest api) и про эту часть фреймворка сказать ничего не могу.я
Ну… я как бы не вижу ничего сложного в этих проектах (в плане архитектуры). Если у нас там чисто REST/HTTP API, мало бизнес логики (по сути у вас там только работа с данными, выборки из базы, возможно CQRS какой-нибудь можно вкатить). То есть конкретно Yii тут мало палок в колеса может поставить (только active record и то сомневаюсь).
Я же говорю о проектах где например есть десяток сущностей с кучей отношений между друг дружкой, с кучей бизнес правил и т.д.
Я же говорю о проектах где например есть десяток сущностей с кучей отношений между друг дружкой, с кучей бизнес правил и т.д.
Из-за NDA не могу там указать подробности работы. Открыто могу расскащать про перую работу в списке — самую свежую.
Сейчас уже 12 крупных модулей, которые с одной стороны полностью изолированны друг от друга, с другой тесно взаимодействуют. Отключение любых из них является штатной ситуацией. Поддерживаются различные версии, кастомизация, версионирование данных. В базе под 500 таблиц. Программных сущностей чуть меньше. Содержит около 2000 классов. Архитектура чистая, гибкая, устойчивая к сбоям. Система работает распределенно на нескольких серверах. Думаю, это можно назвать сложным пректом.
Остальные проекты не такие сложные но по несколько десятков взаимосвязанных сущностей в них есть.
Сейчас уже 12 крупных модулей, которые с одной стороны полностью изолированны друг от друга, с другой тесно взаимодействуют. Отключение любых из них является штатной ситуацией. Поддерживаются различные версии, кастомизация, версионирование данных. В базе под 500 таблиц. Программных сущностей чуть меньше. Содержит около 2000 классов. Архитектура чистая, гибкая, устойчивая к сбоям. Система работает распределенно на нескольких серверах. Думаю, это можно назвать сложным пректом.
Остальные проекты не такие сложные но по несколько десятков взаимосвязанных сущностей в них есть.
Я не спорю что на Yii можно писать нормальные поддерживаемые приложения, особенно если само приложение будет изолировано от фреймворка (хотя бы частично). И уж темболее можно писать адекватно на Yii2.
Я говорю о среднестатистических разработчиках код которых мне приходилось ревьювить. И на проектах чуть сложее интернет магазина уже начинаются проблемы.
Что говорить о том что я нахожу XSS уязвимости в каждом проекте на Yii который приходит ко мне на ревью.
Я говорю о среднестатистических разработчиках код которых мне приходилось ревьювить. И на проектах чуть сложее интернет магазина уже начинаются проблемы.
Что говорить о том что я нахожу XSS уязвимости в каждом проекте на Yii который приходит ко мне на ревью.
Я лично за 6 лет ни разу не видел адекватно написанного проекта на Yii.
Хотел чтобы вы увидели хоть один :)
> Что говорить о том что я нахожу XSS уязвимости в каждом проекте на Yii который приходит ко мне на ревью.
Намекните плз где чаще всего они находятся?
Намекните плз где чаще всего они находятся?
везде где выводятся значения вбиваемые пользователями. Начиная с имени фамилии и заканчивая поиском, комментариями и т.д. Просто не экранируют вывод. + встроенные js библиотечки в Yii (или в экстеншенах) тоже могут чего-нибуть выводить без экранирования.
Ну то есть это не проблема конкретно Yii, а проблема отсуствия шаблонизатора с фильтрацией вывода по дефолту. Средства что бы делать все ок есть в самом Yii но про них не знаю и не пользуются. Так же частенько просто забывают.
Для новичков это черевато проблемами. Им вообще бандаж нужен, а не язык или фреймворк который позволяет все на свете и не ругает ничего.
Ну то есть это не проблема конкретно Yii, а проблема отсуствия шаблонизатора с фильтрацией вывода по дефолту. Средства что бы делать все ок есть в самом Yii но про них не знаю и не пользуются. Так же частенько просто забывают.
Для новичков это черевато проблемами. Им вообще бандаж нужен, а не язык или фреймворк который позволяет все на свете и не ругает ничего.
понятно, спс, в моделях валидатор со strip_tags назначаемый на любые вводимые строковые значения уже видимо решает эту проблему? плюс в стандартных виджетах выводятся строки по умолчанию с экранированием, хотя где выводятся строки без виджетов проследить непросто конечно
вообще я лично считаю это неправильным, менять пользовательские данные. Вдруг человек хотел поделиться в комментариях снипетом кода? Всякое бывает. А тут взяли и порезали. Ну и да, разработчик может и забыть это сделать. Ну и опять же, возможны ситуации когда должны быть разрешены отдельные теги (хотя через strip_tags это можно захэндлить).
Экранирование должно происходить при выводе и лучше автоматически. Об этом даже говорится в документации, правда удобного решения проблемы как бы не приводится. Вариант что использовать, старый добрый htmlspecialchars или какие-то отдельные библиотеки-санитайзеры.
В Twig например экранирование происходит по дефолту, если мы не задали при выводе других параметров. Стандартный вывод значения (
Экранирование должно происходить при выводе и лучше автоматически. Об этом даже говорится в документации, правда удобного решения проблемы как бы не приводится. Вариант что использовать, старый добрый htmlspecialchars или какие-то отдельные библиотеки-санитайзеры.
В Twig например экранирование происходит по дефолту, если мы не задали при выводе других параметров. Стандартный вывод значения (
{{some.prop}}) прогонит значение через фильтр. При желании мы можем подифицировать параметры экранирования через фильтры (raw и т.д.)Про Twig — также работают все стандартные виджеты, тоже по умолчанию используется формат с экранированием, но можно его изменить. Для вывода вне строчек используем функцию шорткат — коротко-удобно и настраивается в одном месте, но опять же конечно надо постоянно следить, чтобы никто не забыл обернуть вывод…
> Им вообще бандаж нужен
как вариант — тим лид хорошо помогает для начала, но не всем с этим везет конечно :)
как вариант — тим лид хорошо помогает для начала, но не всем с этим везет конечно :)
> Если разработчик собирается использовать решение которое поддерживать может только он то от него надо бежать.
Вообще, если исходный код передается заказчику, то ничего страшного. И, у меня есть положительный опыт: я работал в vipro.ru мы писали свою CMS, где все было сделано для людей. Битрикс рядом не валялся.
Вообще, если исходный код передается заказчику, то ничего страшного. И, у меня есть положительный опыт: я работал в vipro.ru мы писали свою CMS, где все было сделано для людей. Битрикс рядом не валялся.
Может вам просто стоит начать искать команды проф. разработчиков для таких проектов, которые вы упоминаете, или сменить место поиска (если задачи на команду не тянут)?
А то возникает чувство (поправьте, если я не прав), что вы пытаетесь в той тусовке, где 90+% заказов «поправить что-то на вордпрессе» найти людей, которые не имеют опыта корпоративной разработки.
А то возникает чувство (поправьте, если я не прав), что вы пытаетесь в той тусовке, где 90+% заказов «поправить что-то на вордпрессе» найти людей, которые не имеют опыта корпоративной разработки.
Честно скажу что мне встречались обратно противоположные сценарии, когда php разработчики превращали проект в серое болото, тут скорее у кого от куда руки растут. Хотя в php еще пару лет назад можно было встретить больше полоруких разработчиков, маслом им что ли там намазано.
Интересно, а есть ли (хотя бы в планах) что-то типа форка РНР, который бы не обеспечивал обратную совместимость, но убирал бы значительную часть костылей древности?
Такой язык никому не нужен. Собственно часть «нападок» на PHP в целом из-за ощущения, что это lagecy. Если в PHP поломают капитально совместимость, то другие языки стоять и ждать не будут.
Именно поэтому я говорю про форк, а не ставлю вопрос «когда-нибудь в РНР уберут уже эту strpos-substr?».
Это личное предположение или результат какого-то исследования?
Такой язык никому не нужен.
Это личное предположение или результат какого-то исследования?
Это личное предположение или результат какого-то исследования?
Результат личного исследования. Новому PHP надо будет сражаться со старым PHP + с Python, Ruby, Go, JS, C# и т.д.
Python 3 — все таки решились, там много не совместимых нововведений, из-за этого на него очень неспешно переходят конечно, но процесс идет
При том, что комьюнити Python с трудом можно назвать консерваторами… у PHP мне кажется с этим будет всё хуже, но тут уже моё личное ИМХО.
Python 3 вышел 7 лет назад, и как широко он используется сейчас?
Через 7 лет после выхода PHP 5.0 он был уже на 90% сайтов.
Через 7 лет после выхода PHP 5.0 он был уже на 90% сайтов.
Я не понимаю как ваш вопрос связан с моим комментарием.
Это был риторический вопрос. По этой статистике только 1% сайтов на Python использует третью версию.
Это тут причём? У PHP разве был рывок когда они поломали полностью обратную совместимость при наличии конкурентов?
ЗЫ интересно как они считали? Я уже как 3 года использую тройку.
ЗЫ интересно как они считали? Я уже как 3 года использую тройку.
у PHP все очень жестко завязано на обратную совместимость (и я не считаю что это плохо). Просто иногда читай php internals начинаешь расстраиваться, ибо некоторые люди сводят хорошие идеи к обсурдным. Но это так же нормальное явление в большом комьюнити. Всегда найдутся недовольные.
Только вчера слышал тот-же вопрос про Java. Опыт Python показывает, что это очень опасно для языка. Хотя «эффект бега с развязанными шнурками» тоже очень неприятная штука. Возможно, самый правильный путь — не остановиться и завязать шнурки, а потихоньку выдавливать «древности» в deprecated и по одной запрещать в каждом следующем релизе. Тогда сразу много всего переписывать не придётся, исправления старого кода будут простыми и вреда будет меньше, чем пользы от отказа от этих вещей. В этом русле собственно и идёт развитие PHP.
Отлично, что есть чей-то опыт, с которым можно сравнить! Согласен, вероятно, это не самый лучший сценарий, но… если бы оно уже было, я бы как минимум попробовал. Очень нравится как развивается РНР в последнее время — и направление, и темпы.
Python к слову вроде наконец до вязал почти все шнурки и троечка становится основой новых проектов. Но мне больше интересен Pyston.
ну как вариант форка — Hack
Не форк, но язык очень похожий на PHP и при этом без костылей: Hack — уже production ready.
Есть ещё JPHP — PHP под JVM, но не уверен насчёт production.
А в целом чем вам мешают «костыли древности»? Просто не пользуйтесь «плохими» частями языка.
Есть ещё JPHP — PHP под JVM, но не уверен насчёт production.
А в целом чем вам мешают «костыли древности»? Просто не пользуйтесь «плохими» частями языка.
Ну вообще PHP 7 — большой шаг в этом направлении, с очень достойной совместимостью
А смысл, если не будет обратной совместимости, можно просто взять любой хороший существующий язык, с уже созданной архитектурой. Или в PHP есть что-то такое уникальное и близкое к вашему сердцу, и вы хотите это сохранить?
Может я ошибаюсь, но среди мэйнстрим языков нет ни одного с такой же легкостью деплоя и прочего администрирования веб-приложений на эталонных реализаций как у PHP. Основной юзкейс PHP в вебе — не апп-сервер, общающийся с веб-сервер, а скрипт, вызываемый веб-сервером. Даже с оберткой php-fpm тот факт, что технически есть fast-cgi сервер, скрывается от разработчика. Для него это всего лишь одноразовый скрипт, который отрабатывает и умирает, что позволяет минимально думать об отдаче ресурсов, даже если бы не было автоматического сборщика мусора.
Давайте посмотрим в интернете, какие проекты все-таки используют PHP:
И выбрали его т.к. на тот момент особо не было альтернативы.
Много критики в адрес PHP основано на вещах, которых не было в языке, когда критикующий в последний раз на него смотрел — в начале нулевых.
Увы, проекты которые написаны на PHP образца нулевых, всё ещё встречаются и осложняют жизнь. А так, сейчас конечно к самому PHP претензий гораздо меньше.
Подскажите как обстоят дела в PHP с написанием долго живущих демонов и асинхронных веб приложений?
Подскажите как обстоят дела в PHP с написанием долго живущих демонов и асинхронных веб приложений?
Кардинально ничего не поменялось. Либо менять архитектуру (например, sub-pub), либо использовать другие инструменты.
Воу, воу. Решений полно, например этот проект затисался уже в php-fig, надеюсь в скором времени увидеть фреймворки с коробочной многопоточностью.
Отличная библиотека кстати, спасибо! Но всё же, проблемы PHP с утечками и т.д. уже исправлены? Где про это можно почитать?
С утечками сталкивался года два-три назад последний раз, но и то можно было списать на мою криворукость.
Думаю, что почитать про актуальные и закрытые утечки можно здесь.
Думаю, что почитать про актуальные и закрытые утечки можно здесь.
Подобные инструменты появились довольно давно. Насколько они стабильны, производительны и надёжны — [для меня] вопрос открытый. Опять-таки, для себя я этот вопрос решил использованием более подходящих инструментов (в моём случае — Go).
Пробовал разбираться с Java. С удивлением обнаружил, что первые изучаемые конструкции мало чем отличаются от PHP. Правда приходится жёстко расписывать какая переменная что хранит, т.е. кода получается больше.
Попробуйте ещё английский поучить. Вы будете приятно удивлены, что там многие слова тоже из PHP заимствованы.
> Правда приходится жёстко расписывать какая переменная что хранит, т.е. кода получается больше.
Если без шуток, то по моему личному опыту строгая типизация — это преимущество, а не недостаток. Лишние байты кода на производительности труда сказываются незаметно, а ряд ошибок/опечаток, которые отлавливаются на этапе компиляции, время и нервы экономят намного больше.
> Правда приходится жёстко расписывать какая переменная что хранит, т.е. кода получается больше.
Если без шуток, то по моему личному опыту строгая типизация — это преимущество, а не недостаток. Лишние байты кода на производительности труда сказываются незаметно, а ряд ошибок/опечаток, которые отлавливаются на этапе компиляции, время и нервы экономят намного больше.
Я к тому, что если нет специфических требований использовать другой язык, то и смысла бросать PHP нет.
А что такое «специфические требования»? Вы в большинстве случаев не сможете использовать Java там, где сможете использовать РНР, и не сможете использовать РНР там, где сможете использовать Java. Несмотря на схожесть закорючек. Изучая Java, вы расширяете свой кругозор в сторону серверов приложений, или разработки для мобильных устройств, например, которые вам недоступны как РНР-программисту.
Вы в большинстве случаев не сможете использовать Java там, где сможете использовать РНР, и не сможете использовать РНР там, где сможете использовать Java.
В большинстве случаев можно использовать и Java, и PHP, и C#, и С, и C++, и asm, и Brainfuck — возражения против того или иного языка носят экономический и религиозный характер в большинстве случаев.
Разве? А мне казалось, что возражения против того или иного языка в подавляющем случае определяются возможностями имеющихся библиотек, фреймворков или сред выполнения, имеющихся для этого языка. И что соответствующие «экосистемы», например, для Java, PHP или С практически не пересекаются. Вы, если вам важен сугубо теоретический результат, сможете написать веб-сайт и на ассемблере. Сделать CGI-приложение, которое генерирует контент, подцепить это к веб-серверу, и оно как-то будет работать. Но в реальном проекте ведь такой вариант вы никогда не будете рассматривать просто по технологическим соображениям. Вы скорее всего даже между взаимозаменяемыми технологиями вроде PHP и ASP.NET выбирать не будете (кроме частных случаев, когда проект делается вообще «на голом месте»), а сузите свой круг выбора до того, что лучше впишется в имеющуюся инфраструктуру. Виндовый домен, майкрософтовский софт, внутреннее корпоративное приложение — будет ASP.NET ± MVC. Публикация на хостинге? Вероятно, PHP или что-то аналогичное. И т.д.
Имеющаяся у заказчика инфраструктура — это чисто экономический вопрос приобретения осей. Но, кстати, современные движения в области системного софта, прежде всего в части виртуализации и контейнерации, вполне допускают запуск PHP-приложений в системах с Windows на железе в виртуальным *nix окружением (вроде как Windows Server 2016 вообще нативно поддерживает запуск Linux и FreeBSD контейнеров Docke), равно как запуск .NET-приложение в *nix окружении. Чем дальше — тем меньше приходится думать разработчику о том под какой осью реально будет крутиться приложения, это становится заботой исключительно администраторов.
Так денюжка — это же универсальный измеритель, и вообще любой вопрос при желании можно свести к экономическому :) Например, можно ли на PHP писать под PDP-11? Да можно, конечно. Нанять программиста, чтобы он портировал интерпретатор под PDP-11, и можно. Сугубо экономический вопрос на трудозатраты, верно?
А если без шуток, то это как раз вопрос технологический. Если инструмент предназначен для выполнения каких-либо задач, но его использование дороже или требует квалификации, то это экономика. Если не предназначен, то это технология. РНР не подходит для работы в Windows-домене, просто потому, что там сама исполняемая среда не имеет вменяемых средств интеграции с Windows-приложениями. Поэтому для таких задач вы действительно не будете его рассматривать. А если вдруг будете — это признак непрофессионализма. Вроде «Я знаю только этот инструмент, поэтому я буду плакать, жрать кактусы, срывать сроки, но упорно крутить костыли, пытаясь его сюда впихнуть».
А если без шуток, то это как раз вопрос технологический. Если инструмент предназначен для выполнения каких-либо задач, но его использование дороже или требует квалификации, то это экономика. Если не предназначен, то это технология. РНР не подходит для работы в Windows-домене, просто потому, что там сама исполняемая среда не имеет вменяемых средств интеграции с Windows-приложениями. Поэтому для таких задач вы действительно не будете его рассматривать. А если вдруг будете — это признак непрофессионализма. Вроде «Я знаю только этот инструмент, поэтому я буду плакать, жрать кактусы, срывать сроки, но упорно крутить костыли, пытаясь его сюда впихнуть».
Смыл бросать php есть когда:
* Нужна выская производительность.
* Нужна поддержка многопоточности.
* Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
* Хочется исключить ошибки, которые можно исключить системой статической типизации.
* Когда достала необходимость ставить доллары перед каждой переменной.
* Нужна выская производительность.
* Нужна поддержка многопоточности.
* Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
* Хочется исключить ошибки, которые можно исключить системой статической типизации.
* Когда достала необходимость ставить доллары перед каждой переменной.
* Нужна выская производительность. -> писать тормозные и тяжелые решения можно на любом ЯП
* Нужна поддержка многопоточности. -> есть много потокобезопасных библиотке
* Хочется исключить ошибки, которые можно исключить системой статической типизации. -> php7
* Нужна поддержка многопоточности. -> есть много потокобезопасных библиотке
* Хочется исключить ошибки, которые можно исключить системой статической типизации. -> php7
писать тормозные и тяжелые решения можно на любом ЯП
Часто используемая технология ограничивает производительность и если производительность действительно нужна — надо менять технологию.
есть много потокобезопасных библиотек
Нету поддержки concurrency в языке.
php7
Развивается язык. Это не может не радовать. Проверка типов при компиляции или в рантайме произходит?
>* Когда достала необходимость ставить доллары перед каждой переменной.
Ну это прям мега довод) Или это изза нынешней финансовой ситуации и ипотеки в валюте?))
>Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
Он там есть.
>* Нужна поддержка многопоточности.
Тоже есть.
>* Нужна выская производительность.
Если нужна высокая производительность то тогда не php надо бросать, а учить с++ и писать частично на нем именно те части, которые требуют высокой производительности, java тут будет не полноценным выходом.
>* Хочется исключить ошибки, которые можно исключить системой статической типизации.
выше написали про php 7, но в целом никто не мешает запилить например ассёрты уже сейчас.
Ну это прям мега довод) Или это изза нынешней финансовой ситуации и ипотеки в валюте?))
>Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
Он там есть.
>* Нужна поддержка многопоточности.
Тоже есть.
>* Нужна выская производительность.
Если нужна высокая производительность то тогда не php надо бросать, а учить с++ и писать частично на нем именно те части, которые требуют высокой производительности, java тут будет не полноценным выходом.
>* Хочется исключить ошибки, которые можно исключить системой статической типизации.
выше написали про php 7, но в целом никто не мешает запилить например ассёрты уже сейчас.
Перед каждой переменной нужно ставить дополнительный символ, которы набирается с шифтом. Это раздражает.
Есть удобный механизм для хранения разделяемых ресурсов в памяти? Чтобы, например, каждый запрос использовал один и тот де коннекшн к БД? Когда я интересовался вопросом, для этого нужно было использовать отдельный сервер. В языке для этого ничего не было.
Есть поддержка многопоточности? Прямо concurrency? Если это так, то язык за последние 2 месяца сделал гигантский прорыв. Можно снипет, как создать 2 потока, которые имеют доступ к разделяемой переменной? Как сделать критическую секцию? Есть ли модификатор volatile?
Всё зависит от требуемой производительности. И наличия легаси кода. С легаси кодом — действительно легче переписывать куски. Если проект новый, то java (дажа java) даст рост производительности в разы.
Закат солнца вручную? Да, приходится иногда делать. Но лучше, когда язык делает за тебя.
Есть удобный механизм для хранения разделяемых ресурсов в памяти? Чтобы, например, каждый запрос использовал один и тот де коннекшн к БД? Когда я интересовался вопросом, для этого нужно было использовать отдельный сервер. В языке для этого ничего не было.
Есть поддержка многопоточности? Прямо concurrency? Если это так, то язык за последние 2 месяца сделал гигантский прорыв. Можно снипет, как создать 2 потока, которые имеют доступ к разделяемой переменной? Как сделать критическую секцию? Есть ли модификатор volatile?
Если нужна высокая производительность то тогда не php надо бросать, а учить с++ и писать частично на нем именно те части, которые требуют высокой производительности, java тут будет не полноценным выходом.
Всё зависит от требуемой производительности. И наличия легаси кода. С легаси кодом — действительно легче переписывать куски. Если проект новый, то java (дажа java) даст рост производительности в разы.
выше написали про php 7, но в целом никто не мешает запилить например ассёрты уже сейчас.
Закат солнца вручную? Да, приходится иногда делать. Но лучше, когда язык делает за тебя.
>Закат солнца вручную? Да, приходится иногда делать. Но лучше, когда язык делает за тебя.
Ну да, а вот в той же java многих бесят постоянные и временами ненужны пляски с типами, да и со многим чем другим.
Ага вот, поэтому появляется что-то вроде scala, которая как java, но не совсем. Почему-то никто не плодит всяких «улучшенных пхп»
>Есть удобный механизм для хранения разделяемых ресурсов в памяти?
>Чтобы, например, каждый запрос использовал один и тот де коннекшн к БД?
Это т.е. несколько хттп запросов к пхп и конекшен один? А зачем так? Берем тогда phpDaemon, производительность у него на уровне nodeJS. Если именно ресурсы как данные, то apc есть.
>Есть поддержка многопоточности? Прямо concurrency?
Сыплете терминами всякими, прям как гуманитарий какой. Мы то люди простые, вы задачу опишите, которую хотите решить, там и понятно будет может это пхп или нет. На счет же всяческих указателей компилятору что оптимизировать что нет, тут конечно же нет.
>Если проект новый, то java (дажа java) даст рост производительности в разы.
Ну да, правда есть такой огромный шанс, что когда его на java напишут он уже нафиг никому не нужен будет.
С пхп все несколько веселее, прототип — за месяц на коленке, тут главное опыт иметь и чтот-то вроде архитектуры придумать. Далее можно тупо кусками тяжелые моменты запиливать, например, демонами на с++. На больших данных и тяжелых манипуляциях с ними — с++ джаву сделает только в путь.
Ну да, а вот в той же java многих бесят постоянные и временами ненужны пляски с типами, да и со многим чем другим.
Ага вот, поэтому появляется что-то вроде scala, которая как java, но не совсем. Почему-то никто не плодит всяких «улучшенных пхп»
>Есть удобный механизм для хранения разделяемых ресурсов в памяти?
>Чтобы, например, каждый запрос использовал один и тот де коннекшн к БД?
Это т.е. несколько хттп запросов к пхп и конекшен один? А зачем так? Берем тогда phpDaemon, производительность у него на уровне nodeJS. Если именно ресурсы как данные, то apc есть.
>Есть поддержка многопоточности? Прямо concurrency?
Сыплете терминами всякими, прям как гуманитарий какой. Мы то люди простые, вы задачу опишите, которую хотите решить, там и понятно будет может это пхп или нет. На счет же всяческих указателей компилятору что оптимизировать что нет, тут конечно же нет.
>Если проект новый, то java (дажа java) даст рост производительности в разы.
Ну да, правда есть такой огромный шанс, что когда его на java напишут он уже нафиг никому не нужен будет.
С пхп все несколько веселее, прототип — за месяц на коленке, тут главное опыт иметь и чтот-то вроде архитектуры придумать. Далее можно тупо кусками тяжелые моменты запиливать, например, демонами на с++. На больших данных и тяжелых манипуляциях с ними — с++ джаву сделает только в путь.
> Это т.е. несколько хттп запросов к пхп и конекшен один? А зачем так?
Хм. Хороший вопрос. Я вспомнил, как лет семь назад писал к PHP свой экстеншен, только для того, чтобы была возможность обеспечить один разделяемый пул коннектов в рамках всех запросов. Потому что иначе сервер просто ложился под нагрузкой.
Хм. Хороший вопрос. Я вспомнил, как лет семь назад писал к PHP свой экстеншен, только для того, чтобы была возможность обеспечить один разделяемый пул коннектов в рамках всех запросов. Потому что иначе сервер просто ложился под нагрузкой.
Ложился только от коннектов? Странно. Или вы так что-то вроде кеширования намутили?
Если речь идет про то что база не справлялась, то понятно дело, что PHP тут не причем.
Если же про то что application сервер падал, ну т.е. там где PHP крутится — то тут у нас все делается по другому, таких серверов ставится несколько, добавляются по мере необходимости, пока их пара десятков это выгодно, т.к. железо в целом стоит дешевле программистов :)
Если речь идет про то что база не справлялась, то понятно дело, что PHP тут не причем.
Если же про то что application сервер падал, ну т.е. там где PHP крутится — то тут у нас все делается по другому, таких серверов ставится несколько, добавляются по мере необходимости, пока их пара десятков это выгодно, т.к. железо в целом стоит дешевле программистов :)
Ничего странного. Любой коннект к базе — это значительные накладные расходы на сам коннект плюс на поддержание пользовательской сессии в СУБД. Поэтому если есть возможность их переиспользования, производительность вырастает очень существенно. В моем случае единый пул коннектов вообще убрал в этом узле проблему производительности как класс, без необходимости наращивать мускулы железяке. Это только кажется, что сервер дешевле программиста. Обычно оценивают только стоимость самого сервера, но при этом забывают, что на чашу весов сервера надо положить ещё его установку, конфигурирование и далее эксплуатационное обслуживание, причем тоже живыми людьми с вполне недешевым рабочим временем. Плюс, новый сервер — новая точка отказов.
>Ничего странного. Любой коннект к базе — это значительные
>накладные расходы на сам коннект плюс на поддержание пользовательской сессии в СУБД.
Коннект по сравнению со всем остальным это копейки обычно, опять же непонятно что вы такое делали? Да и что за база была? Ну ни разу даже не слышал про проблему с такой стороны. У вас был пучок пхп скриптов запущенных как демоны? Вообще обычно узкое место — это хранение данных, т.е. сколько можем записать прочитать, какой язык это уже дело второе.
> Это только кажется, что сервер дешевле программиста.
Так можно посмотреть на цены, ну и мы же не имеем ввиду джуниоров работающих за еду в роли программиста?
> Обычно оценивают только стоимость самого сервера, но при этом забывают,
> что на чашу весов сервера надо положить ещё его установку,
>конфигурирование и далее эксплуатационное обслуживание,
>причем тоже живыми людьми с вполне недешевым рабочим временем.
Сочувствую, что вам приходится работать с людьми, которые забывают столь важные вещи)
Впрочем я про то, что 10 или 20 серверов разницы по поддержке почти нет, они же типовые будут. Все разворачивается и настраивается почти автоматом, если, конечно, все профессионально делать. Сейчас огромная куча разных программных средств, которые очень сильно облегчают работу. По сути добавление сервера сводится к загрузке образа и запуску установочного скрипта. Для мониторинга также есть куча всяких средств.
>Плюс, новый сервер — новая точка отказов.
Это вы вообще про что?) Ну как бэ банально балансер же можно настроить, чтоб он дальше запрос перекидывал, если какое-то железо сдохло)
>накладные расходы на сам коннект плюс на поддержание пользовательской сессии в СУБД.
Коннект по сравнению со всем остальным это копейки обычно, опять же непонятно что вы такое делали? Да и что за база была? Ну ни разу даже не слышал про проблему с такой стороны. У вас был пучок пхп скриптов запущенных как демоны? Вообще обычно узкое место — это хранение данных, т.е. сколько можем записать прочитать, какой язык это уже дело второе.
> Это только кажется, что сервер дешевле программиста.
Так можно посмотреть на цены, ну и мы же не имеем ввиду джуниоров работающих за еду в роли программиста?
> Обычно оценивают только стоимость самого сервера, но при этом забывают,
> что на чашу весов сервера надо положить ещё его установку,
>конфигурирование и далее эксплуатационное обслуживание,
>причем тоже живыми людьми с вполне недешевым рабочим временем.
Сочувствую, что вам приходится работать с людьми, которые забывают столь важные вещи)
Впрочем я про то, что 10 или 20 серверов разницы по поддержке почти нет, они же типовые будут. Все разворачивается и настраивается почти автоматом, если, конечно, все профессионально делать. Сейчас огромная куча разных программных средств, которые очень сильно облегчают работу. По сути добавление сервера сводится к загрузке образа и запуску установочного скрипта. Для мониторинга также есть куча всяких средств.
>Плюс, новый сервер — новая точка отказов.
Это вы вообще про что?) Ну как бэ банально балансер же можно настроить, чтоб он дальше запрос перекидывал, если какое-то железо сдохло)
Со «всем остальным» — это какое остальное вы имеете в виду? Найти запись по индексу в таблице? Нет, коннект обычно будет осуществляться дольше. Сложный запрос с кучей условий/объединений, и потом обновление по нему? Ну да, коннект обычно будет осуществляться быстрее. И то, и другое — достаточно типовые задачи. Поэтому что тут смущает, непонятно. Конкретно эта система — это был автомат для платежной системы, который должен был быстро молотить выборки по состоянию счетов для сети собственных терминалов и гейтов банков.
> Так можно посмотреть на цены, ну и мы же не имеем ввиду джуниоров работающих за еду в роли программиста?
_Любого программиста_ Сколько стоит, скажем, месяц работы хорошего программиста? Ну четыре-пять тысяч долларов в столице. Если он потратит пару недель своей работы на то, чтобы сэкономить на установку целого сервера, это окупится за полгода.
> Впрочем я про то, что 10 или 20 серверов разницы по поддержке почти нет, они же типовые будут.
Т.е. в тех задачах, где можно было просто оптимизировать код, вы предлагаете не просто забить на оптимизацию, а поставить уже даже не дополнительный сервер, а целую ферму. И развернуть инфраструктуру для обслуживания этого добра. Мне кажется, экономическую часть вашего диплома вы в своё время завалили :)
> Это вы вообще про что?) Ну как бэ банально балансер же можно настроить, чтоб он дальше запрос
> перекидывал, если какое-то железо сдохло)
Ну да, только это будет для следующего запроса, а не тех, которые были на железке в момент сбоя. И то, когда железо перестанет откликаться. И в том сферическом случае, когда у вас такой сервис, который всё-таки предполагает целую ферму серверов в кластере.
> Так можно посмотреть на цены, ну и мы же не имеем ввиду джуниоров работающих за еду в роли программиста?
_Любого программиста_ Сколько стоит, скажем, месяц работы хорошего программиста? Ну четыре-пять тысяч долларов в столице. Если он потратит пару недель своей работы на то, чтобы сэкономить на установку целого сервера, это окупится за полгода.
> Впрочем я про то, что 10 или 20 серверов разницы по поддержке почти нет, они же типовые будут.
Т.е. в тех задачах, где можно было просто оптимизировать код, вы предлагаете не просто забить на оптимизацию, а поставить уже даже не дополнительный сервер, а целую ферму. И развернуть инфраструктуру для обслуживания этого добра. Мне кажется, экономическую часть вашего диплома вы в своё время завалили :)
> Это вы вообще про что?) Ну как бэ банально балансер же можно настроить, чтоб он дальше запрос
> перекидывал, если какое-то железо сдохло)
Ну да, только это будет для следующего запроса, а не тех, которые были на железке в момент сбоя. И то, когда железо перестанет откликаться. И в том сферическом случае, когда у вас такой сервис, который всё-таки предполагает целую ферму серверов в кластере.
>Если он потратит пару недель своей работы на то,
>чтобы сэкономить на установку целого сервера, это окупится за полгода.
Откуда такие цифры как пара недель и целого сервера? Обычно речь идет о процентах, ну мыж не говорим о системе которую писали джуниоры и ни разу не проверяли под нагрузками?
>Т.е. в тех задачах, где можно было просто оптимизировать код, вы предлагаете не просто забить
>на оптимизацию, а поставить уже даже не дополнительный сервер, а целую ферму.
Нет я лишь говорю что вы асбоютно не правы, и что в нормальном проекте для еще десятка серверов не придется заводить в два раза больше админов.
>Мне кажется, экономическую часть вашего диплома вы в своё время завалили :)
А вы похоже сдали с отличием?) Похвастайтесь в каком вузе так пофиг на дипломы)
Впрочем если без стеба тут хватит школьной математики:
Мой опыт показывает, что сервис на java дольше разрабатывается, раза в два, прогеры в целом стоят больше, а в результате выйгрыш на серверах раза в два в лучшем случае. Если говорить о проекте, который изначально заведомо успешный, то согласен, php я бы для него не выбрал, однако обычно рулит скорость старта. Ну и также покупать серваки смысл есть не всегда, есть аренда, а там окупаемость совсем другая. Возможно у вас другой опыт, но без цифр и предметной области это будет всего лишь тупой спор.
>Ну да, только это будет для следующего запроса, а не тех, которые были на железке в момент сбоя.
Чтото я туплю, но разве повысится статистически шанс потерять запрос при увеличении количества серверов и таком же количестве запросов? Учитывая что время обработки сильно отличаться не будет.
>чтобы сэкономить на установку целого сервера, это окупится за полгода.
Откуда такие цифры как пара недель и целого сервера? Обычно речь идет о процентах, ну мыж не говорим о системе которую писали джуниоры и ни разу не проверяли под нагрузками?
>Т.е. в тех задачах, где можно было просто оптимизировать код, вы предлагаете не просто забить
>на оптимизацию, а поставить уже даже не дополнительный сервер, а целую ферму.
Нет я лишь говорю что вы асбоютно не правы, и что в нормальном проекте для еще десятка серверов не придется заводить в два раза больше админов.
>Мне кажется, экономическую часть вашего диплома вы в своё время завалили :)
А вы похоже сдали с отличием?) Похвастайтесь в каком вузе так пофиг на дипломы)
Впрочем если без стеба тут хватит школьной математики:
Мой опыт показывает, что сервис на java дольше разрабатывается, раза в два, прогеры в целом стоят больше, а в результате выйгрыш на серверах раза в два в лучшем случае. Если говорить о проекте, который изначально заведомо успешный, то согласен, php я бы для него не выбрал, однако обычно рулит скорость старта. Ну и также покупать серваки смысл есть не всегда, есть аренда, а там окупаемость совсем другая. Возможно у вас другой опыт, но без цифр и предметной области это будет всего лишь тупой спор.
>Ну да, только это будет для следующего запроса, а не тех, которые были на железке в момент сбоя.
Чтото я туплю, но разве повысится статистически шанс потерять запрос при увеличении количества серверов и таком же количестве запросов? Учитывая что время обработки сильно отличаться не будет.
> Откуда такие цифры как пара недель и целого сервера? Обычно речь идет о процентах
Цифры условные. Я просто обозначил порядок. Мы ведь говорили об оптимизации, которая позволит обойтись без кластера.
> Нет я лишь говорю что вы асбоютно не правы, и что в нормальном проекте
> для еще десятка серверов не придется заводить в два раза больше админов.
Вы просто забыли сначала упомянуть, что «нормальный проект» в вашем понимании — это когда трудится большая ферма с балансировщиком нагрузки, и плюс десяток/минус десяток серверов, это не проблема. Т.е. остальные 99.99% проектов, которые прекрасно помещаются на одном хосте, не нормальные. Но я всё-таки имею в виду большинство, а не достаточно редкий частный случай.
> Мой опыт показывает, что сервис на java дольше разрабатывается, раза в два, прогеры в целом стоят
> больше, а в результате выйгрыш на серверах раза в два в лучшем случае.
Мы вообще про Java сейчас не говорили, а только про РНР :) По-всякому бывает на самом деле. И в любом случае, эти две платформы крайне редко конкурируют в рамках одного или даже одинаковых проектов.
> Ну и также покупать серваки смысл есть не всегда, есть аренда, а там окупаемость совсем другая.
Математика тут простая. Любой облачный провайдер будет нести те же затраты на сервер, что и вы, плюс он ещё платит свои налоги и хочет поиметь прибыль. Экономия для клиентов достигается за счет того, что облачный провайдер разделяет свои ресурсы между многими клиентами, каждый из которых «в среднем» потребляет чуть-чуть от арендуемой мощности. Если же ваш проект употребляет сервер «под завязку», вам всегда будет дешевле иметь собственный сервер, чем арендовать.
> Чтото я туплю, но разве повысится статистически шанс потерять запрос при увеличении количества
> серверов и таком же количестве запросов?
Нет, статистически не повысится. Речь была о том, что балансер — не панацея от проблем, и не избавит клиентов от потери транзакции.
Цифры условные. Я просто обозначил порядок. Мы ведь говорили об оптимизации, которая позволит обойтись без кластера.
> Нет я лишь говорю что вы асбоютно не правы, и что в нормальном проекте
> для еще десятка серверов не придется заводить в два раза больше админов.
Вы просто забыли сначала упомянуть, что «нормальный проект» в вашем понимании — это когда трудится большая ферма с балансировщиком нагрузки, и плюс десяток/минус десяток серверов, это не проблема. Т.е. остальные 99.99% проектов, которые прекрасно помещаются на одном хосте, не нормальные. Но я всё-таки имею в виду большинство, а не достаточно редкий частный случай.
> Мой опыт показывает, что сервис на java дольше разрабатывается, раза в два, прогеры в целом стоят
> больше, а в результате выйгрыш на серверах раза в два в лучшем случае.
Мы вообще про Java сейчас не говорили, а только про РНР :) По-всякому бывает на самом деле. И в любом случае, эти две платформы крайне редко конкурируют в рамках одного или даже одинаковых проектов.
> Ну и также покупать серваки смысл есть не всегда, есть аренда, а там окупаемость совсем другая.
Математика тут простая. Любой облачный провайдер будет нести те же затраты на сервер, что и вы, плюс он ещё платит свои налоги и хочет поиметь прибыль. Экономия для клиентов достигается за счет того, что облачный провайдер разделяет свои ресурсы между многими клиентами, каждый из которых «в среднем» потребляет чуть-чуть от арендуемой мощности. Если же ваш проект употребляет сервер «под завязку», вам всегда будет дешевле иметь собственный сервер, чем арендовать.
> Чтото я туплю, но разве повысится статистически шанс потерять запрос при увеличении количества
> серверов и таком же количестве запросов?
Нет, статистически не повысится. Речь была о том, что балансер — не панацея от проблем, и не избавит клиентов от потери транзакции.
Коннект по сравнению со всем остальным это копейки обычно, опять же непонятно что вы такое делали?
Установка соединения это вечность. Если по запросу надо только вернуть небольшой кусок данных, а это характерно для REST API — большая часть времени будет затрачена именно на установку соединения.
Как бы отдавать напрямую данные из базы довольно фиговая ситуация, однако в среднем большая часть должна быть покрыта кешами.
Обработка данных это тоже мгновения. А запросы к бд кешируются, но надо сначала установить коннект.
Именно такие комментарии и делают плохую репутацию пхп разработчикам. Вам стоит почитать Тенебаума прежде чем что-то утверждать. И даю подсказку — чтобы взять данные из кеша к нему тоже стоит подключиться, т.е. установить коннект.
Всё зависит от времени формирования этого куска. Одно дело выбор одной строки по ключу из уникального индекса, совсем другое сложный агрегирующий запрос, почти не использующий индексы.
Не могу не накинуть чуть справедливости по поводу постоянных коннектов php.net/manual/en/features.persistent-connections.php
Они есть и очень очень давно.
Они есть и очень очень давно.
А это не совсем то, что требовалось. Нужен был именно пул подключений, с возможностью наращивания числа открытых коннектов при росте нагрузки на узел, и с их высвобождением, и т.д.
Ну как бы, это можно реализовать поверх pconnect. Да и в чем смысл организовывать пул своими силами, если у нас и так есть ограничения, сколько одновременно запросов может обрабатываться (по количеству воркеров). А держать постоянно открытыми 3-4 соединения в принципе не затратно.
Все же другие варианты где это имеет смысл (ну или я вижу в этом смысл) только в контексте демонов. И даже в этом случае «экстеншены» свои писать не надо.
Все же другие варианты где это имеет смысл (ну или я вижу в этом смысл) только в контексте демонов. И даже в этом случае «экстеншены» свои писать не надо.
В рамках скрипта PHP ведь не организуешь — он отработал и ушёл. Разделяемых ресурсов как таковых там нет, чтобы как-то организованно управлять пулом. Плюс, была необходимость вешать запросы в очередь при заполнении пула, т.к. количество лицензий на подключение к базе данных было лимитировано «сверху». Я уже всех деталей не вспомню, всё-таки столько времени прошло, но помню, что проблему со всех сторон мучили, прежде чем решиться на разработку экстеншена. И pconnect, и конфигурированием апача, и т.д.
В рамках скрипта PHP ведь не организуешь — он отработал и ушёл.
в этом суть pconnect, соединение с базой кешируется и реюзается в рамках воркера. Если вы не закрыли соединение вы сможете его реюзать потом.
Плюс, была необходимость вешать запросы в очередь при заполнении пула
опять же, у вас ограниченное количество воркеров (пых синхронный по дефолту), у каждого свое соединение, не надо никаких очередей.
В целом я думаю что разработка экстеншена для управление соединением с базой это… мягко скажем дикая крайность. Потому меня так и заинтересовало выяснить причины — любопытно какие задачи это решало.
Ага вот, поэтому появляется что-то вроде scala, которая как java, но не совсем.
Которая как джава, но не совсем это groovy. scala это совсем не как джава, но исполняемая в джава машине.
Почему-то никто не плодит всяких «улучшенных пхп»
В основном потому, что это технически сложно. Сделать новый язык, который будет исполняться в джава манине —
задача отностительно простая. Автоматом этот язык будет иметь доступ к джава коду.
Поэтому таких языков много.
Ну и есть ещё одна причина. Когда java программист уставал от джавы у него не было альтернатив. Так и
появились эти языки. У программиста на php альтернатив море — начиная от ruby и кончая Go. Для перехода с
php ему не надо ничего, кроме желания.
Это т.е. несколько хттп запросов к пхп и конекшен один? А зачем так?
Чтобы не поднимать новый коннекшн на каждый запрос.
Берем тогда phpDaemon, производительность у него на уровне nodeJS. Если именно ресурсы как данные, то apc есть.
Вот я и говорю, удобно это не сделаешь. Только приблудами всякими.
Сыплете терминами всякими, прям как гуманитарий какой.
Эти термины знает каждый программист. Кроме тех, конечно, которые используют языки не поддерживающие многопоточность.
Чтобы раскрыть что такое многопоточность и зачем она нужна нужно написать целую книгу и не одну.
php многопоточность, увы не поддреживает.
На счет же всяческих указателей компилятору что оптимизировать что нет, тут конечно же нет.
volatile нужен не для оптимизации, а чтобы прорамма вообще работала.
Ну да, правда есть такой огромный шанс, что когда его на java напишут он уже нафиг никому не нужен будет.
Всё, что делается на php быстро на джаве делается примерно с той же скоростью. То, что на php делать долго, на джаве, как правило делается быстрее.
С пхп все несколько веселее, прототип — за месяц на коленке, тут главное опыт иметь и чтот-то вроде архитектуры придумать. Далее можно тупо кусками тяжелые моменты запиливать, например, демонами на с++.
На джаве примерно так же, только можно не запиливать демоны.
На больших данных и тяжелых манипуляциях с ними — с++ джаву сделает только в путь.
Большие данные это зачастую Hadoop и Spark.
>Перед каждой переменной нужно ставить дополнительный символ, которы набирается с шифтом. Это раздражает.
Ну детский сад, ну IDE уже наконец настройте чтобы он за вас это делал. Вы еще скажите что по пять мегабайт кода в день пишите, что от лишнего нажатия на шифт устаете.
Ну детский сад, ну IDE уже наконец настройте чтобы он за вас это делал. Вы еще скажите что по пять мегабайт кода в день пишите, что от лишнего нажатия на шифт устаете.
Перед каждой переменной нужно ставить дополнительный символ, которы набирается с шифтом. Это раздражает.
Если этот аргумент серьезно рассматривается, то PHP умрёт (или, хотя бы, опустится до доли Perl-а — когда-то своего основного конкурента) очень не скоро :) Плюс в явном разделении пространств имён переменных и других сущностей есть свои плюсы. Как минимум меньше ограничений при выборе имён.
«Если нужна высокая производительность то тогда не php надо бросать, а учить с++ и писать частично на нем именно те части, которые требуют высокой производительности, java тут будет не полноценным выходом.»
Просто интереса ради почитайте про HFT, а, заодно, на чём там пишут. Не ручаюсь за полный список языков, но java там точно участвует и не на последних ролях.
">Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
Он там есть."
Вот прям не велосипеды и не Mongo/etc, а прямо сервер приложений/ядро оного на языке, способные обслуживать множество запросов? И скрипт не грузится перед каждым выполнением заново? Если так — мои поздравления, язык наконец-то начинает подбираться к промышленным/«энтерпрайз»-языкам.
Просто интереса ради почитайте про HFT, а, заодно, на чём там пишут. Не ручаюсь за полный список языков, но java там точно участвует и не на последних ролях.
">Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
Он там есть."
Вот прям не велосипеды и не Mongo/etc, а прямо сервер приложений/ядро оного на языке, способные обслуживать множество запросов? И скрипт не грузится перед каждым выполнением заново? Если так — мои поздравления, язык наконец-то начинает подбираться к промышленным/«энтерпрайз»-языкам.
>Просто интереса ради почитайте про HFT
Ок спасибо, просто в некоторых задачах на практике c++ показал себя сильно намного лучше, возможно я что-то делал не так.
>И скрипт не грузится перед каждым выполнением заново?
Да это давно уже нет, nginx воркеры все такое, а есть еще hhvm
>Вот прям не велосипеды и не Mongo/etc, а прямо сервер приложений/ядро оного на языке,
>способные обслуживать множество запросов?
Можно и так сделать, только смысла особого не имеет, реализации общей памяти да, могут показаться надстройкой, однако для решения задач вполне себе хватает и пользоваться в целом удобно.
Ок спасибо, просто в некоторых задачах на практике c++ показал себя сильно намного лучше, возможно я что-то делал не так.
>И скрипт не грузится перед каждым выполнением заново?
Да это давно уже нет, nginx воркеры все такое, а есть еще hhvm
>Вот прям не велосипеды и не Mongo/etc, а прямо сервер приложений/ядро оного на языке,
>способные обслуживать множество запросов?
Можно и так сделать, только смысла особого не имеет, реализации общей памяти да, могут показаться надстройкой, однако для решения задач вполне себе хватает и пользоваться в целом удобно.
Большинство сравнений, где с/с++ выигрывают больше нескольких процентов — неудачная реализация на Java. Есть случаи, когда Java действительно плохо подходит, но их не так уж и много.
Пока сам не работал с джавой — даже не задавался мыслями о пользе разделяемых данных… правда я достаточно быстро ушел на Java (о чём не жалею) и вот тут уже и увидел пользу.
Пока сам не работал с джавой — даже не задавался мыслями о пользе разделяемых данных… правда я достаточно быстро ушел на Java (о чём не жалею) и вот тут уже и увидел пользу.
Если смотреть совсем узко, то Java тупо ест на порядок меньше ресурсов на отрисовку такой же страницы. Плюс Java — это язык, на котором написан весь сервер, а не только модуль для Apache, хотя насколько это важное преимущество — ещё вопрос.
Там, где есть LAMP, смысла бросать PHP точно нет. Вообще смысл «бросать» что-то бывает довольно редко.
Там, где есть LAMP, смысла бросать PHP точно нет. Вообще смысл «бросать» что-то бывает довольно редко.
PHP — это не только модуль для Apache. Можно и без Apache вполне обойтись используя Nginx для отдачи статики и проксирования запросов к PHP-FPM. На счёт ресурсов ничего не могу сказать. Измерений не делал. Но при небольшой нагрузке связка работает и на виртуалке с 512Мб помяти.
Про вас уже писали, что вы застряли в прошлом десятилетии. Какой модуль apache?!
Можно поподробнее про «на порядок»? И что считается «ресурсами на отрисовку» — память, выделяемая при запуске сервера до прихода первого запроса туда входит или нет? Как минимум, потребляемая память состоит из постоянных ресурсов на поднятие сервера и ресурсов потребляемых на один запрос (а после него освобождаемых).
Ну да, а ABAP использует такой гигант как SAP.
Facebook использует не чистый php, и разрабатывают Hack.
Есть такое понятие, как legacy. Возможно компании до сих пор используют php, просто потому, что у них нет выбора: переписывать будет очень дорого.
P.S. Какой удобный пост, чтобы словить минусов в карму
Facebook использует не чистый php, и разрабатывают Hack.
Есть такое понятие, как legacy. Возможно компании до сих пор используют php, просто потому, что у них нет выбора: переписывать будет очень дорого.
P.S. Какой удобный пост, чтобы словить минусов в карму
Ну так пусть ноют. И валят куда подальше. У остающихся будет выше зарплата )))
А если серьезно — то у PHP на ближайшие лет пять альтернативы нет. И вряд ли появится. Особенно это очевидно стало с выходом PHP 7.
А если серьезно — то у PHP на ближайшие лет пять альтернативы нет. И вряд ли появится. Особенно это очевидно стало с выходом PHP 7.
Вангую угрозу со стороны JS после реализации классов и прочего ООП. Над nodeJS работает очень много крутых специалистов с мощным матаном, сам не пользую, но наработки типа libUV очень впечатляют.
Конечно не пять лет, но не будем зарекаться, впрочем.
Конечно не пять лет, но не будем зарекаться, впрочем.
Я про пять лет потому, что это как раз средний срок жизни технологий и экосистем. PHP уже третий такой срок переживает (условно — «старый», «пятерка» и теперь «семерка») и ничего — делается только лучше.
Не вижу я угрозы со стороны JS, вот что хотите делайте. Не в состоянии себе среднестатистический джуниор быстро и решительно сломать себе мозг, чтобы хорошо писать на JS. На PHP же за год активной работы любое криворучье при наличии вменяемого тьютора доводит себя до промышленных стандартов.
Не вижу я угрозы со стороны JS, вот что хотите делайте. Не в состоянии себе среднестатистический джуниор быстро и решительно сломать себе мозг, чтобы хорошо писать на JS. На PHP же за год активной работы любое криворучье при наличии вменяемого тьютора доводит себя до промышленных стандартов.
На nodeJS большой проект писать и поддерживать дороже, там не только с ООП проблемы, их там еще оч много, пока все допилят и привыкнут, те же лет пять точно пройдут а скорее намного больше.
Критика нужна, даже неконструктивная! Вернитесь на те же 10 лет назад и всспомните какой поток негатива изливался на Java, всё ещё живо предубеждение что Java тормозной, хотя быстродействие кода в 99% зависит от прокладки между ТЗ и кодом. Критикуется то что развивается, имхо.
Уверен что через 10 лет не меньше критики будет в отношении JS.
Уверен что через 10 лет не меньше критики будет в отношении JS.
В отношении JS и сейчас немало критики, но разница в том, что JS безальтернативен для фронтенда (если не учитывать языки, компилирующиеся в JS, типа TS или CS).
На фоне критики php, критика JS — это ворчание из угла. То ли ещё будет когда начнётся массовое использование стека с nodejs…
Как 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 настолько отвратительного качества, что появляются мысли на подобие «ужасный язык», хотя он лишь инструмент и все зависит от того, как его использовать.
php-разработчики любят php
python-разработчики обожают python
ruby-разработчики влюблены в ruby
js-разработчики на одном месте вертели js (повторюсь, чисто мое ИМХО)
Посмотрите сами — каждый день появляется по десятку библиотек и фреймворков, в которых авторы пытаются закрыть несовершенство языка. Раз в год появляются крупные и громкие релизы, которые переворачивают всю разработку с ног на голову (jQuery, потом Backbone, потом Angular и Ember, вот недавно React, ждем, что же будет дальше). Раз в три-четыре года появляются надстройки типа CoffeScripts, Dart, TypeScript, EJX, которые теперь еще начали перемешиваться между собой с адской силой. Теперь еще и релизы ES каждый год. Браузеры еще в ES6 толком не могут (нативно), а на подходе ES7 (ES2016 вроде, теперь по годам называют), который вдобавок ужасно вкусный.
Ну и все это заправлено соусом из пугающих новичков странных правил вывода типа, кучи мест с граблями, всплытия переменных и рвущим пришедшим из других языков мозг прототипным ООП.
Но, как будто бы этого мало — чтобы быть топовым разработчиком, необходимо знать это все сразу. Кучу самых новых и адски старых библиотек, технологий, сборщиков. И мало того, чтобы просто знать — нужно постоянно отслеживать новейшие подходы. Облизываться, вытирать слюнки и продолжать пилить проект на легаси, потому что если начнешь переделывать — не успеешь, обязательно выйдет что-то еще новее, еще круче. И вот, ты мегакрутой разработчик, используешь самые передовые технологии, сходил в отпуск на месяц, вернулся — уже устарел и бомж в свой стартап не позовет.
Так что в отношении JS очень много критики. Просто она какая-то не такая отъявленная, покуда выхода то нет… С другой стороны, не припомню ни одного другого столь стремительно развивающегося и обрастающего библиотеками языка.
Что касается PHP — язык как язык. Со своими недостатками и преимуществами. Мне сильно подпортило впечатление о нем, что у него очень низкий порог входа, в следствие чего, многие начинают свою карьеру разработчиками именно с него, а в итоге приходится работать с кучей Legacy настолько отвратительного качества, что появляются мысли на подобие «ужасный язык», хотя он лишь инструмент и все зависит от того, как его использовать.
Есть язык программирования С на котором написано на порядки больше, чем на php. Никто, однако, (кроме разве что Линуса Торвальдса) не спорит, что у него есть объективные недостатки.
В случае с php ситуация похожа, только хуже. Недостатков куча (чего стоит только одна необходимость ставить знак доллара перед каждой переменной), а вот из достоинств только низкий порог входа и повсеместная распространённость на хостингах. Мало того, есть вещи, которые php просто не может (например concurrency).
Так что программистам на этом языке можно только поапплодировать. Используя очень ограниченный инструмент они умудряются создавать отличные высококачественные продукты.
Это делает честь программистам, но ничего не меняет в том, чем на данный момент является php. Правда я, как и многие другие, ещё помню времена, когда не было и того. php постепенно развивается и возможно когда-нибудь он изменится настолько радикально, что критиковать его станет сложно. Но это момент ещё не наступил.
В случае с php ситуация похожа, только хуже. Недостатков куча (чего стоит только одна необходимость ставить знак доллара перед каждой переменной), а вот из достоинств только низкий порог входа и повсеместная распространённость на хостингах. Мало того, есть вещи, которые php просто не может (например concurrency).
Так что программистам на этом языке можно только поапплодировать. Используя очень ограниченный инструмент они умудряются создавать отличные высококачественные продукты.
Это делает честь программистам, но ничего не меняет в том, чем на данный момент является php. Правда я, как и многие другие, ещё помню времена, когда не было и того. php постепенно развивается и возможно когда-нибудь он изменится настолько радикально, что критиковать его станет сложно. Но это момент ещё не наступил.
НЛО прилетело и опубликовало эту надпись здесь
Вчера только новость проскакивала, что госдума призывает отказаться от php из-за необходимости использования знака доллара
.Перед каждой переменной нужно набрать символ, для набора которого надо зажать шифт. Кто-то будет спорить с тем, что это неудобно и глупо? Кто-то скажет, что это даёт хоть какие-то преимущества?
Меньше вариантов в автокомплите? :)
НЛО прилетело и опубликовало эту надпись здесь
Вы про то, что нужно указывать тип переменной? Да, есть такой косяк. Во многих языках его потепенно устраняют автоматическим выводом типа.
Но, в отличие от доллара в php, тип в java надо указать только при объявлении, а не при каждом использовании. И, в отличие от доллара в php, польза от статической типизации огромна и неоценима.
Но, в отличие от доллара в php, тип в java надо указать только при объявлении, а не при каждом использовании. И, в отличие от доллара в php, польза от статической типизации огромна и неоценима.
Обычно в Java тип переменной автоматически проставляется с помощью IDE;-). Это если, конечно, не хочется специально поупражняться и понабивать шишки в блокноте…
С чего хоть вы взяли, что в PHP низкий порог входа? Это настолько распространенный, насколько же и неверный миф.
PHP — сложный язык. Реально сложный. И хорошо писать на нем не легче, чем на Java, например.
P.S. Посмотрел в мониторинге, как себя чувствует мой демон, написанный на PHP, работающий с Websokets (чат между клиентами и менеджерами). Чувствует нормально. Аптайм — две недели. Что я делаю не так?
PHP — сложный язык. Реально сложный. И хорошо писать на нем не легче, чем на Java, например.
P.S. Посмотрел в мониторинге, как себя чувствует мой демон, написанный на PHP, работающий с Websokets (чат между клиентами и менеджерами). Чувствует нормально. Аптайм — две недели. Что я делаю не так?
Для того, чтобы просто взять и начать писать — на php достаточно низкий порог входа. Ниже, чем у большинства других языков. Причем, этого низкого уровня достаточно, чтобы клепать сайты-визитки. Однако многие, почему-то, считают, что этого им достаточно и пытаются начинать пилить большие проекты. Как аналогия — научиться прятать формочки при клике на крестик в js можно за 5 секунд гугления: $('#button').click('form').slideUp(). Вот только между подобной конструкцией и строчкой «я знаю js» — пропасть в несколько лет. Так же и в php — между страничкой с инлайновыми SQL запросами до «я знаю php» — большая разница. Вот только часто люди, находящиеся на первом этапе, идут в разработчики, которые потом разрастаются, становятся неподдерживаемыми и их даже страшно открывать.
P.S. И, в конце концов, смотря с чем сравнивать. На PHP гораздо проще научиться писать, чем на том же C, C++, D или ASM, Haskell, F# и erlang. Про verilog, vhdl и lustre (на нем кто-то пишет?) промолчим, по уровню вхождения до ним всем далеко.
P.S. И, в конце концов, смотря с чем сравнивать. На PHP гораздо проще научиться писать, чем на том же C, C++, D или ASM, Haskell, F# и erlang. Про verilog, vhdl и lustre (на нем кто-то пишет?) промолчим, по уровню вхождения до ним всем далеко.
$('#button').click(() => {
$('form').slideUp();
});
Конечно же, что это со мной.
Тогда уж
$('#button').on('click', (e)=>{
$('#form').slideUp();
e.preventDefault();
});
.on('click', ...) позволит вешать больше одного обработчика на кнопку, а preventDefault на случай, если вы всё-же не собираетесь отправить форму этой кнопкой.
$('#button').on('click', (e)=>{
$('#form').slideUp();
e.preventDefault();
});
.on('click', ...) позволит вешать больше одного обработчика на кнопку, а preventDefault на случай, если вы всё-же не собираетесь отправить форму этой кнопкой.
Я про начинающих разработчиков. Какие там preventDefault? Только return false; только хардкор. Да и какие arrow functions? Кому нужны эти babel, сборщики?
Ну и тогда уж $('form').on('submit'...), чтобы максимально корректным. Ну и если это единственная вставка js, то vanillaJS наше все. Но это отдельный разговор.
Ну и тогда уж $('form').on('submit'...), чтобы максимально корректным. Ну и если это единственная вставка js, то vanillaJS наше все. Но это отдельный разговор.
С чего хоть вы взяли, что в PHP низкий порог входа?
Очень много простых задач, для решения которых язык почти не надо знать. Типа добавить текущую дату в какую-нибудь талицу. И за это уже заплатят деньги.
PHP — сложный язык. Реально сложный.
Да, это так. И это ужасно. Сложность — для языка программирования не достоинство.
И хорошо писать на нем не легче, чем на Java, например.
Да, хорошо писать на Java значительно легче. Хотя экосистема Php в последнее время во многом копирует экосистему java.
НЛО прилетело и опубликовало эту надпись здесь
Что неправда? То, что php повсеместно распространён? Или про низкий порог входа?
НЛО прилетело и опубликовало эту надпись здесь
Какие ещё у php есть достоинства по сравнению с другими языками?
Share nothing.
Реализуемо в любом языке.
Да, только в случае PHP когда внезапно прилетает проект «ааа!!! трафик!!!» можно что-то сделать потому как share-nothing по умолчанию, а вот в случае, например, Java, чаще всего уже поздно.
Если проект пишут неопытные разработчики, то наверное так и есть. Но такие с трафиком в любом случае будут иметь сложности. А если разработчики понимают, что делают, то у джавы есть огромное количество проверенных методов распараллеливания кода. По принципу делай раз, делай два, делай три.
В том-то и дело, что внезапно выстреливший прототип на PHP (а прототипы не стоит делать за 100500$ сразу потому что они чаще всего не выстреливают) можно заставить справиться с нагрузкой пока реализуется чистовая версия проекта. На Java во-первых по финансам у нас получится 2 прототипа вместо 20 на PHP, а во-вторых по скорости эти прототипы будут выдаваться раз в несколько медленней.
Ну собственно как я и говорил. Квалификация программистов на php ниже, стоят они дешевле, прототип собирают дешевле. Быстрее, чем у джава программистов с нормальной квалификацией, правда, не получится. Но стоить будет действительно меньше. В том числе поэтому php и пользуется такой популярностью.
А вот чтобы прототип кто-то хоть раз переписывал начисто я не видел вообще никогда :(.
А вот чтобы прототип кто-то хоть раз переписывал начисто я не видел вообще никогда :(.
Большой выбор серьёзных и развивающихся фреймворков.
Большой выбор серьёзных и развивающихся фреймворков есть в java, ruby, python, go, c#, scala. Пара веб фреймворков есть даже для С++. Это не отличает php от всего остального.
Так мы киллер-фичи ищем или просто плюсы перечисляем?
Ну и имелось ввиду что фреймворки ориентированы на вэб и их много. Кроме RoR и django ничего сравнимого с symphony, yii, laravel etc не вспоминается.
Пара же фреймворков на плюсах пригодны для эмбедед только. А про java в вэб отписывался SamDark
Ну и имелось ввиду что фреймворки ориентированы на вэб и их много. Кроме RoR и django ничего сравнимого с symphony, yii, laravel etc не вспоминается.
Пара же фреймворков на плюсах пригодны для эмбедед только. А про java в вэб отписывался SamDark
Вы правы, насчёт того, что кроме RoR и Django нет ничего особо известного, не считая вариантов с Flask, Bottle, Sinatra
но есть такой нюанс — данные фреймворки так или иначе повлияли на имеющиеся в PHP.
та же ситуация и с библиотеками, например, behat, на который повлиял cucumber.
но я сходу не вспомню фреймворков/библиотек, на которые повлияли Symfony, Laravel, Yii.
да, PHP развивается, я как PHP-программист очень этому рад.
но иногда создаётся впечатление, что PHP играет «в догонялки» с другими языками.
а я бы искренне хотел, чтобы на PHP-инструменты равнялись, при создании инструментов в других языках
но есть такой нюанс — данные фреймворки так или иначе повлияли на имеющиеся в PHP.
та же ситуация и с библиотеками, например, behat, на который повлиял cucumber.
но я сходу не вспомню фреймворков/библиотек, на которые повлияли Symfony, Laravel, Yii.
да, PHP развивается, я как PHP-программист очень этому рад.
но иногда создаётся впечатление, что PHP играет «в догонялки» с другими языками.
а я бы искренне хотел, чтобы на PHP-инструменты равнялись, при создании инструментов в других языках
Какая разница, кто был первый?
Yii повлиял на Symfony, Laravel и совсем немного на RoR. Они, в свою очередь, повлияли на Yii. Мы не в вакууме живём и у разработчиков фреймворков не священная война, а обмен опытом.
Yii повлиял на Symfony, Laravel и совсем немного на RoR. Они, в свою очередь, повлияли на Yii. Мы не в вакууме живём и у разработчиков фреймворков не священная война, а обмен опытом.
Разница есть в том, что тот кто первый, первый и находит недочёты и исправляет их.
В тех же рельсах уже давно как отказались от настроек массового присваивания для моделей и обосновали почему — я с ними полностью согласен. А в Eloquent до сих пор protected $fillable и меня это, как PHP-разработчика, немного угнетает — чувствуется именно отставание.
Не надо, конечно же, демонизировать PHP — вполне себе неплохой развивающийся язык. Но надо всё же признать, что ряд вещей в том же python с ruby и, соответственно, фреймворках, сделаны намного удобнее и яляются более зрелыми именно по причине первости.
В тех же рельсах уже давно как отказались от настроек массового присваивания для моделей и обосновали почему — я с ними полностью согласен. А в Eloquent до сих пор protected $fillable и меня это, как PHP-разработчика, немного угнетает — чувствуется именно отставание.
Не надо, конечно же, демонизировать PHP — вполне себе неплохой развивающийся язык. Но надо всё же признать, что ряд вещей в том же python с ruby и, соответственно, фреймворках, сделаны намного удобнее и яляются более зрелыми именно по причине первости.
Как-бы нет. Видит и исправляет недочёты второй, если этот второй не тупо копирует, а понимает, что делает. Первый уже завязался на ошибки. Надо обратную совместимость сохранить и так такое.
Конечно, если сравнивать фреймворк с десятилетней историей, стабильными версиями и всем таким с чем-то новым-трендовым, но чему пара лет и версии выплёвываются без обратной совместимости как пирожки, то да. Тут очевидна зрелость и не зрелость. Но в общем случае нет…
Мы в Yii ещё в 2010 переделали умолчания для массового присвоения несмотря на то, как делали в рельсах. Рельсы с GitHub и Хомяковым прилично на этом погорели через несколько лет. Тейлор в Laravel тоже много всего поправил при заимствовании (из Yii 1.1 много штук было ещё в Laravel 3), хотя ему тяжелее. Он фактически в одиночку пилил до недавнего времени фреймворк и, к тому же, ему постоянно надо думать, как с фреймворка получить денег потому как это его основное занятие. Это несколько смещает приоритеты и отвлекает.
Что-то в RoR и Django лучше, но что-то хуже.
Конечно, если сравнивать фреймворк с десятилетней историей, стабильными версиями и всем таким с чем-то новым-трендовым, но чему пара лет и версии выплёвываются без обратной совместимости как пирожки, то да. Тут очевидна зрелость и не зрелость. Но в общем случае нет…
Мы в Yii ещё в 2010 переделали умолчания для массового присвоения несмотря на то, как делали в рельсах. Рельсы с GitHub и Хомяковым прилично на этом погорели через несколько лет. Тейлор в Laravel тоже много всего поправил при заимствовании (из Yii 1.1 много штук было ещё в Laravel 3), хотя ему тяжелее. Он фактически в одиночку пилил до недавнего времени фреймворк и, к тому же, ему постоянно надо думать, как с фреймворка получить денег потому как это его основное занятие. Это несколько смещает приоритеты и отвлекает.
Что-то в RoR и Django лучше, но что-то хуже.
но я сходу не вспомню фреймворков/библиотек, на которые повлияли Symfony
Джанга )
Я стараюсь перечислить плюсы, которые отличают php от других решений. Большое количество хороших фреймворков к таковым не принадлежит ибо характерно не только для php.
Для java есть play framework, есть Spring который на первый взгляд ну очень поход на laravel, только чутка поудобнее, для scala есть play framework2. Для go названий не помню, но там тоже есть.
Что есть на php, чего нет на других языках это Wordpress :).
Судя по тому, что пишет SamDark он немного отпустил руку с пульса. :)
Для java есть play framework, есть Spring который на первый взгляд ну очень поход на laravel, только чутка поудобнее, для scala есть play framework2. Для go названий не помню, но там тоже есть.
Что есть на php, чего нет на других языках это Wordpress :).
Судя по тому, что пишет SamDark он немного отпустил руку с пульса. :)
НЛО прилетело и опубликовало эту надпись здесь
Да, я под веб давно ничего на Java не делал. Последний раз это были Spring и Wicket. Ну и, конечно, Hibernate и ещё туча всякой тяжёлой дряни. Сейчас Java использую для Android. Очень приятно.
Сейчас у 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 и радуешься.
Те кто говорят, что разработка на Java в n раз медленнее X скриптового языка, просто видимо не трогали Java с тех пор(или вообще не трогали и судят с позиции диванного теоретика), как все умные люди поняли, что JavaEE это вообще не комильфо.
В последнее время еще очень понравился Play2, там все так же удобно только «нативненько» со Scala и очень многое доступно «из коробки», плюс очень большой упор на асинхронность.
Ко всему прочему, не нужны никакие XML не для сборки, не для конфигов(и Spring и Play поддерживают «нормальные» конфиги; билдить и подтягивать зависимости в Gradle/Sbt весьма удобно). Пишешь код на том на чем больше «штырит» под JVM и радуешься.
Ладно, это всё выше — болтология. Неплохо сформулирована проблема в статье: дискредитация профессиональная и в оплате из-за предубеждений к конкретному стеку технологий.
Дискриминация профессиональная — потому, что подавляющее большинство программистов на php имеют низкую квалификацию. Дискриминация по оплате — потому, что большиство задач стоящих перед программистами на php не требуют высокой квалификации для решения.
Высококвалифицированных программистов никто не будет упрекать в том, что они используют php, недостатки которого им самим хорошо известны.
Высококвалифицированных программистов никто не будет упрекать в том, что они используют php, недостатки которого им самим хорошо известны.
Вооот, яркий пример — ваше же высказывание. Большинство программистов на любом ЯП имеют квалификацию ниже среднего, ибо градация так сделана, чтобы на 5 мидл один сеньёр приходился, условно. Я знаяю мало плохих программистов, пишущих на php, гораздо больше скрипт-кидди от python и js. А, ещё «плюсисты» полторы лабы скатавшие в универе часто встречаются. Самый плохой вариант php-быдлокодеров — это мамонты, которым ничего кроме легаси десятилетней давности не дававали. Были и на хабре статьи, затрагивающие актуализацию стека, и на тостере трогательные (в хорошем смысле) вопросы встречаются про то как бы вырваться из прошлого.
Упрекают за php, инстенктивно, поддаваясь стадному чувству. Совсем свежий анектод: «А зачем вам phalcon, вот у нас круто из фронта запросы строить!» (хз что за стек они используют).
Упрекают за php, инстенктивно, поддаваясь стадному чувству. Совсем свежий анектод: «А зачем вам phalcon, вот у нас круто из фронта запросы строить!» (хз что за стек они используют).
Какой выбор фреймворков в C#, например? Там есть ASP.NET и все… по большому счету
>Есть язык программирования С на котором написано на порядки больше, чем на php.
>Никто, однако, (кроме разве что Линуса Торвальдса) не спорит, что у него есть объективные недостатки.
Фигня в том, что PHP прост, а вот изучить нормально С «обсирателям» уже не получается, поэтому гавнакод на С кажется им адски крутой магией.
>Никто, однако, (кроме разве что Линуса Торвальдса) не спорит, что у него есть объективные недостатки.
Фигня в том, что PHP прост, а вот изучить нормально С «обсирателям» уже не получается, поэтому гавнакод на С кажется им адски крутой магией.
>Тех, кто учит PHP, надо изолировать от общества
Раз так ненавидят, значит боятся! правильным путем двигаемся!
Раз так ненавидят, значит боятся! правильным путем двигаемся!
НЛО прилетело и опубликовало эту надпись здесь
Главный недостаток PHP, по-моему, это даже не знаки доллара перед переменными и не согласованные сигнатуры стандартных функций, а тот факт, что многие вещи задаются настройками самого интерпретатора, подключаемыми к нему расширениями и т.д.
Ввиду чего использование того же composer несколько ограничено. Раньше, видимо, поэтому и сделали общесистемный PEAR по аналогии с расширениями.
В каком ещё интерпретируемом языке такое есть?
Ввиду чего использование того же composer несколько ограничено. Раньше, видимо, поэтому и сделали общесистемный PEAR по аналогии с расширениями.
В каком ещё интерпретируемом языке такое есть?
В Ruby?
В Ruby нет разницы между библиотекой и расширением — это всё gem-ы.
По-умолчанию они ставятся в систему, с появлением bundler-а куда хочется — чаще всего в папку с проектом, т.е. не нужны права суперпользователя.
Но и в первом случае нет никаких системных ruby.ini файлов, которые задают как должны работать проекты, использующие его.
По-умолчанию они ставятся в систему, с появлением bundler-а куда хочется — чаще всего в папку с проектом, т.е. не нужны права суперпользователя.
Но и в первом случае нет никаких системных ruby.ini файлов, которые задают как должны работать проекты, использующие его.
Мне кажется, что позиционирование себя как «программиста на языке х» вообще изначально ущербно. Синтаксис, концепции, парадигмы они во многих языках схожи, есть исчисляемое количество подходов к написанию программ. Сильно ли визуально отличается код на Java, C++, C#?
Если есть база, то новый язык выучить не так уж и сложно, не сложнее, чем очередной фреймворк. Сложнее понять новую парадигму, другую модель памяти.
Если есть база, то новый язык выучить не так уж и сложно, не сложнее, чем очередной фреймворк. Сложнее понять новую парадигму, другую модель памяти.
НЛО прилетело и опубликовало эту надпись здесь
а опыт, а ньюансы? чем больше кода пишешь на языке тем продуктивнее становишься. новый язык все равно будет не привычен.
Сильно ли визуально отличается код на Java, C++, C#По какому-то странному стечению обстоятельств перечислены только языки со строгой типизацией, а два из них так и вообще безопасные;-)
Если из списка отбросить C++, то оставшиеся два — точно не столько из серии «программист на языке х», сколько из серии «программист под платформу y», позиционирование себя как «программиста под платформу y» уже не ущербно. А вот PHP, Python, JavaScript, Visual Basic — это да, «программист на языке». C++ такой большой, что сам как платформа. Но и то тут рпаспадается на области: PHP, Python, Node JS — это «веб», JavaScript (безальтернативно) — «клиентский веб», Visual Basic — «под Windows», C++ — «под Windows» и «низкоуровневое». Так что у тех, кто «на языке», есть смежная область, куда можно расширять кругозор…
Вот и отечественный язык Parser-3 находится едва ли не в худшем положении. Многие до сих пор принимают его за шаблонизатор Parser-2, который закончился в далеком 2002м, а кто-то до сих пор ассоциирует с полной багов поделкой Parser первой версии. В то время как это тьюринг-полный объектный язык, поддерживаемый и развивающийся, а встроенность конструкций в html и возможность покраски данных делают его едва ли не лучшим языком для веб-разработки небольших проектов.
встроенность конструкций в html и возможность покраски данных
А разве не за это раньше ругали PHP? Ну или ругают, те, у кого знания о РНР >= 10 летней давности. Это уж точно не повод для гордости и не аргумент за «лучшесть для веба».
Для динозавров: PHP сейчас слава б-гам уже давно отошел от этой парадигмы, если что. Сейчас HTML только через шаблонизаторы принято делать.
Возможно, в случае с PHP тогда проблема была в его кривости, а не во встраиваемости. Я видел и то и другое, меня коробит от встроенных <? но конструкции с ^ выглядят вполне читабельно, особенно если правильно подсветить.
Хотя скорее, дело в том, что мы слишком увлеклись MVC, и спешим выбросить всё, что в него не укладывается.
Хотя скорее, дело в том, что мы слишком увлеклись MVC, и спешим выбросить всё, что в него не укладывается.
Эх, а я так надеялся, что ваш первый коммент про Parser был сарказмом :) было бы гораздо смешнее
Меня тоже коробит от <?, поэтому в моём коде всегда ровно один <?php в начале файла и никаких ?> (и то, он проставляется автоматически PhpStorm'ом). С html работает шаблонизатор twig, в котором синтаксис, ИМХО, гораздо органичнее вписывается в html, чем php или тот же parser.
И да, посмотрел на сайт парсера, судя по датам релизов, он уже начинает отдавать мертвичинкой. А слова apache и cgi заставили нервно дёрнуться. Как в этом вообще можно жить?
И да, посмотрел на сайт парсера, судя по датам релизов, он уже начинает отдавать мертвичинкой. А слова apache и cgi заставили нервно дёрнуться. Как в этом вообще можно жить?
Как жить? Если это помогает решать задачи лучше чем другие варианты, то вполне комфортно. Сейчас все популярные инструменты перешли в раздел командной разработки, с максимально жесткой типизацией, многоуровневыми библиотеками объектов и ограничением тех практик, которые в командной работе могут приводить к хаосу. Их даже стали называть «плохими практиками», придав определению характер абсолюта, безусловности.
Но для индивидуального разработчика все эти вещи только тормозят работу. Всё, что ему нужно — готовая среда и управление видом страницы в коде. Как Arduino.
Но для индивидуального разработчика все эти вещи только тормозят работу. Всё, что ему нужно — готовая среда и управление видом страницы в коде. Как Arduino.
Это так забавно. Иногда складывается впечатление, что проблема PHP-программистов в том, что они PHP-программисты.
Поясню.
Официально я PHP-программист. Т.е. зарабатываю этим денег. Много.
Но я могу говнокодить на любом языке программирования. Из недавнего вот приходилось на Erlang, C++ и, конечно же, bash script.
Я уж не говорю про Питон, Руби и ещё тут ваше название. Может на brainfuck с разбегу не напишу, но уверяю вас через час тоже наговнокодю.
Любой язык это инструмент. Любой инструмент нужно знать и уметь пользоваться.
До смешного доходит, когда люди узнают, что в языке есть такие конструкции:
Начинают к языку отношения менять (сарказмЪ).
Если ты не знаешь, что такое кеширование, ORM, паттерны, какая разница на чем писать?
Проблема не в языке, а в образовании, как бы не банально это звучало.
Поясню.
Официально я PHP-программист. Т.е. зарабатываю этим денег. Много.
Но я могу говнокодить на любом языке программирования. Из недавнего вот приходилось на Erlang, C++ и, конечно же, bash script.
Я уж не говорю про Питон, Руби и ещё тут ваше название. Может на brainfuck с разбегу не напишу, но уверяю вас через час тоже наговнокодю.
Любой язык это инструмент. Любой инструмент нужно знать и уметь пользоваться.
До смешного доходит, когда люди узнают, что в языке есть такие конструкции:
// Контекст: опции передаются в консольный скрипт
if ($this->getOpt()->{'log-path'})
return $this->getOpt()->{'log-path'};
Начинают к языку отношения менять (сарказмЪ).
Если ты не знаешь, что такое кеширование, ORM, паттерны, какая разница на чем писать?
Проблема не в языке, а в образовании, как бы не банально это звучало.
На Java под какой-нибудь сервер приложений вы что-нибудь писали?
Но Вы же прекрасно понимаете, что таких PHP разработчиков как Вы сравнительно маленький процент, в отношении тех кто дальше PHP никуда не смотрел. Как показывает практика, люди, нашедшие в себе силы, изучив любой другой язык, на PHP назад почти не возвращаются. Отсюда риторический вопрос — «Почему!?».
Изучение новых технологий, платформ, языков всегда дает плюс, хотя бы с точки зрения знаний альтернативных решений той или иной задачи.
P.S. сам начинал писать на PHP. Вовремя перешел на Java, последние пол года очень зацепила Scala. Ни один день в своей жизни не жалел, что инвестировал свое время в изучение новых языков.
Изучение новых технологий, платформ, языков всегда дает плюс, хотя бы с точки зрения знаний альтернативных решений той или иной задачи.
P.S. сам начинал писать на PHP. Вовремя перешел на Java, последние пол года очень зацепила Scala. Ни один день в своей жизни не жалел, что инвестировал свое время в изучение новых языков.
Три-четыре последние года следую схеме «каждый год изучить новый ЯП». Писал и на Java, и понравилcя Scala, но реально пригодилися только узкоспециализированный R.
Как по мне, так специализацию надо строить от области применения знаний, а не стека технологий. Вэб сейчас ограничен php/python/js/ror.
Как по мне, так специализацию надо строить от области применения знаний, а не стека технологий. Вэб сейчас ограничен php/python/js/ror.
Перешёл с Java на PHP для веб, ни разу не жалел :)
Распространённая история.
Не нужно выдавать исключение из правил за повсеместное явление )
Плюс ко всему, Вы видимо хорошо понимаете Ваши задачи и для чего конкретно Вам нужен PHP. А не просто потому-что «мне на форуме подсказали что PHP рулит и теперь буду со всеми спорить и говорить что он самый хороший, хотя даже не знаю с чем сравнить» (с)
Плюс ко всему, Вы видимо хорошо понимаете Ваши задачи и для чего конкретно Вам нужен PHP. А не просто потому-что «мне на форуме подсказали что PHP рулит и теперь буду со всеми спорить и говорить что он самый хороший, хотя даже не знаю с чем сравнить» (с)
Александр что с подвигло на переход?
1. Относительно сложный и не быстрый билд и деплой.
2. Spring и тяга всей команды делать в приложении столько же слоёв, сколько там… а лучше ещё больше. Wicket был получше, но ынтырпрайзить от этого не перестали.
3. Дебаг Hibernate, нахождение бага в нём и попытка его поправить.
4. Конфиги в XML адовой вложенности.
5. «Отличное» отношение к вопросам на всех форумах кроме доброго лося.
6.…
2. Spring и тяга всей команды делать в приложении столько же слоёв, сколько там… а лучше ещё больше. Wicket был получше, но ынтырпрайзить от этого не перестали.
3. Дебаг Hibernate, нахождение бага в нём и попытка его поправить.
4. Конфиги в XML адовой вложенности.
5. «Отличное» отношение к вопросам на всех форумах кроме доброго лося.
6.…
Ну, это у кого как путь лег.
Я начинал с Visual Basic + ASP, потом микроконтроллеры (хотя это не очень честно, там был «визуальный» язык программирования).
Потом c++. А потом PHP. Хочу уточнить, что это мой путь только с коммерческой точки зрения. Я получал за это деньги. И остался на PHP.
Так получилось, что я лучше всего знаю как готовить именно его.
Так что я из тех, кто ушел в PHP. Да, много знакомых уходит, изучив новый ЯП. А потом пишут о проблемах с версиями в питоне, отсутствием окружения для явы на продашене, криворуких писателей библиотек для C++ и т.д.
Учить язык, не обязательно. Нужно просто всегда учиться. Узнавать что-то новое.
Каждый делает как может. Кто-то делает интерпретатор brainfuck на php.
Мне проще столкнуться с задачей и решить её новыми инструментами или почитать умных людей.
Нужно просто инвестировать своё время, как вы правильно выразились. А уж в новые языки, чтение Робина Мартина, или интерпретаторы, это кому что.
Я начинал с Visual Basic + ASP, потом микроконтроллеры (хотя это не очень честно, там был «визуальный» язык программирования).
Потом c++. А потом PHP. Хочу уточнить, что это мой путь только с коммерческой точки зрения. Я получал за это деньги. И остался на PHP.
Так получилось, что я лучше всего знаю как готовить именно его.
Так что я из тех, кто ушел в PHP. Да, много знакомых уходит, изучив новый ЯП. А потом пишут о проблемах с версиями в питоне, отсутствием окружения для явы на продашене, криворуких писателей библиотек для C++ и т.д.
Учить язык, не обязательно. Нужно просто всегда учиться. Узнавать что-то новое.
Каждый делает как может. Кто-то делает интерпретатор brainfuck на php.
Мне проще столкнуться с задачей и решить её новыми инструментами или почитать умных людей.
Нужно просто инвестировать своё время, как вы правильно выразились. А уж в новые языки, чтение Робина Мартина, или интерпретаторы, это кому что.
По всей видимости ваша «практика» касается в основном студентов, которые 2 месяца пописали на php, а потом решили, что php это не солидно, когда остальные пишут на крутых JS/Ruby/Scala.
Изучение JS не заставило меня переписать всё на Node.js. Изучение питона с его костылями вроде GIL и подчеркиваний для приватных свойств было увлекательным, но не более того. Примерно то же самое можно и про Java и Go сказать. Нормальные инструменты для своих задач, но отнюдь не повод отказываться от php, тем более имея большой опыт его готовки и зная большинство его подводных камней и ограничений.
Изучение JS не заставило меня переписать всё на Node.js. Изучение питона с его костылями вроде GIL и подчеркиваний для приватных свойств было увлекательным, но не более того. Примерно то же самое можно и про Java и Go сказать. Нормальные инструменты для своих задач, но отнюдь не повод отказываться от php, тем более имея большой опыт его готовки и зная большинство его подводных камней и ограничений.
Как показывает практика, люди, нашедшие в себе силы, изучив любой другой язык, на PHP назад почти не возвращаются. Отсюда риторический вопрос — «Почему!?».
Возможно потому, что как здесь уже говорили — php хорош как язык для начинающих, ибо «начать делать» можно быстро. С Си, Джавой и прочими «Мощными и проверенными временем» решениями не сравниться. Мой опыт веб-программирования начался с php. Можно сказать от скуки решил сделать маленький полезный проект, взял книжку, читал её три дня, а потом начал кодить и недельки за две уже было годное под мои задачи приложение. При полном отсутствии опыта разработки под веб до того времени. Думаю мало какой ещё язык позволяет так легко начать делать что-то реальное (для себя). Потом я увлёкся вебом, пару лет писал на пхп, но познакомился с пайтон-джанго. После Joomla это было невероятно круто. А дальше началась полноценная разработка под веб, пришлось заняться фронт-эндом, а потом и нодой. В итоге сейчас мне порой любопытно чтож там твориться-то в пхп. Однако есть гораздо более интересные вещи на которые и трачу время, а к пхп вернутся нет стимула. И дело не в языке. Мы в компании используем иной стек технологий, так что мне это просто не к чему. Думаю у многих ситуация схожая. Когда пхп первый язык, то возвращается к нему поздно — т.к. ты уже не одиночка и надо оглядываться на команду.
P.S. По теме топика — мне кажется, зачастую нападки на язык больше из-за людей, которые на нём пишут. Всё-таки я очень много встречал упоротых Пыхеров (я иначе их не назову, без обид) которые ничего кроме раздражения не вызывают. И язык на котором они пишут виноват только в том, что он в начале прост настолько, что даже упоротые быдлокодеры смогли им овладеть.
Кто-то писал, что перешел с PHP на Go, но после того как в PHP 7 появились новые фичи (в особенности поддержка статической типизации) вернулся обратно в PHP )
Почему самоущещение автора и других PHP разработчиков должно изменить мое отношение к этому языку? Каким образом использование PHP в Facebook делает его хорошим языком? Язык – это спецификация. И язык PHP – это плохой язык. Объективно плохой. И если специалист не может смирится с этим фактом, пользуйясь принципом «все равно его не брошу потому что он хороший», то тогда профессиональность такого специалиста можно поставить под сомнение.
«На удивление хорошо знаешь информатику для PHP-разработчика»
В чем вина человека, сказавшего это, если большинство PHP-разработчиков объективно плохо знают информатику?
«На удивление хорошо знаешь информатику для PHP-разработчика»
В чем вина человека, сказавшего это, если большинство PHP-разработчиков объективно плохо знают информатику?
Языки уже дано не только и не столько спецификация, а сколько конкретные реализации и сложившиеся вокруг них экосистемы.
И у вас есть объективные данные, конечно же?
В чем вина человека, сказавшего это, если большинство PHP-разработчиков объективно плохо знают информатику?
И у вас есть объективные данные, конечно же?
«Языки уже дано не только и не столько спецификация, а сколько конкретные реализации и сложившиеся вокруг них экосистемы.В более широком смысле – да, только что это меняет? По сравнению с другими языками у PHP впечатляющая реализация? Или фантастическая экосистема?
И у вас есть объективные данные, конечно же?К сожалению, я не занимаюсь аналитикой в подобных вопросах, но могу попробовать порассуждать логически и объяснить, почему такое утверждение мне кажется истинным. Даже в статье есть некоторые факты, которые указывают на это: „есть несколько причин, по которым новые разработчики выбирают PHP...“
Я думаю, вы не будете спорить, что начинающие разработчики хуже разбираеются в computer scince, чем опытные? Именно эти начинающие, которых в PHP больше, чем в других языках, портят статистику для PHP: средний PHP разработчик выглядит менее образованным на фоне разработчиков на других языках. В качестве показательного контрпримера возьмите Haskell – мало для кого этот ЯП был первым, или даже вторым.
Так что это тоже самое, что „средняя женщина управляет автомобилем хуже, чем средний мужчина“ или „средний чернокожий зарабатывает меньше, чем средний европеоид“. Кому-то эти утверждения могут показаться не очень тактичным или приятным, но от этого они не становится менее объективными, потому что есть общая тенденция.
Или фантастическая экосистема?
Не фантастическая, но очень и очень конкурентоспособная. Только связка LAMP+WordPress чего стоит.
Именно эти начинающие, которых в PHP больше, чем в других языках
Голословно. Как по мне, то куда больше начинающих на JavaScript. И начинающие на PHP разбираются в информатике, как правило, лучше начинающих на JavaScript по объективно-статистическим причинам: PHP в подавляющем большинстве случаев используется в связке «клиент-сервер» или в трехзвенной архитектуре, а JS — только на клиенте.
средняя женщина управляет автомобилем хуже, чем средний мужчина
Вроде как статистика опровергает.
Не фантастическая, но очень и очень конкурентоспособная. Только связка LAMP+WordPress чего стоит.Насколько мне известно, стало действительно приемлемо за последние годы, но это точно не козырь PHP. Как-то не вижу я толп желающих пересесть не PHP из других языков, потому что у PHP хорогая экосистема. Может не туда смотрю?
Что такого особенного в связке LAMP+WordPress я вообще не понимаю. Объясните?
Голословно. Как по мне, то куда больше начинающих на JavaScript.Может быть, но как по мне что PHP, что Javascript – два сапога пара. Извините, но в «javacsript все еще хуже» – это не сильный аргумент. Я оба языка считаю не удачными. И javascript тут оправдывает только то, что альтернативы к сожалению нет.
Вроде как статистика опровергает.Как скажете.
> Что такого особенного в связке LAMP+WordPress я вообще не понимаю. Объясните?
Я с нулевым опытом в веб-дизайне могу сесть и сделать за день сайт, такой же, какой профессиональная студия сделает за месяц и много денег. Мой сайт будет выглядеть профессионально, поддерживать разные броузеры и размеры экранов и т.д. Да, он будет тяжелым и тормознутым. Но во многих случаях клиент смотрит на внешний вид.
Это такой себе Delphi для веб-разработчиков.
Я с нулевым опытом в веб-дизайне могу сесть и сделать за день сайт, такой же, какой профессиональная студия сделает за месяц и много денег. Мой сайт будет выглядеть профессионально, поддерживать разные броузеры и размеры экранов и т.д. Да, он будет тяжелым и тормознутым. Но во многих случаях клиент смотрит на внешний вид.
Это такой себе Delphi для веб-разработчиков.
Я с нулевым опытом в веб-дизайне могу сесть и сделать за день сайт, такой же, какой профессиональная студия сделает за месяц.
Не сможете. Вернее сможете, но если вы вообще не будете делать свой дизайн.
и много денег.
Да, много денег возьмут, есть такая тема.
Мой сайт будет выглядеть профессионально, поддерживать разные броузеры и размеры экранов и т.д. Да, он будет тяжелым и тормознутым.
Обратите внимание, вы только что стали php разработчиком. Потому, что получили деньги за работу с php. А потом люди удивляются откуда о php разработчиках предвзятое мнение.
Но во многих случаях клиент смотрит на внешний вид.
Не во многих случаях, а всегда.
> Не сможете. Вернее сможете, но если вы вообще не будете делать свой дизайн.
«Свой дизайн» — не смогу. Но полезность Вордпресса как раз в том, что он избавляет от необходимости делать свой дизайн. Я смогу купить за сумму порядка $50 одну из множества гибко настраиваемых и профессионально сделанных тем, и мышкой настроить её так, как будет красиво. И заказчик будет доволен, он не увидит внешней разницы между «разработать и сверстать» и «нарисовать мышкой».
> Обратите внимание, вы только что стали php разработчиком. Потому, что получили деньги за работу с php.
> А потом люди удивляются откуда о php разработчиках предвзятое мнение.
Ну как сказать… вот Libre Office написан на C++. Означает ли скачивание этого пакета и создание документов в нем то, что вы стали разработчиком С++?
WordPress — это прикладное приложение, среда для быстрой разработки сайтов вообще без навыков веб-разработки. Конечно же, зная PHP и JavaScript, вы можете делать сайты в ней лучше, преодолевать ограничения тем и самой среды, но прелесть WordPress как раз в том, что это знание опциональное, а не обязательное. И это опять ответ на ваш вопрос:
> Что такого особенного в связке LAMP+WordPress
«Свой дизайн» — не смогу. Но полезность Вордпресса как раз в том, что он избавляет от необходимости делать свой дизайн. Я смогу купить за сумму порядка $50 одну из множества гибко настраиваемых и профессионально сделанных тем, и мышкой настроить её так, как будет красиво. И заказчик будет доволен, он не увидит внешней разницы между «разработать и сверстать» и «нарисовать мышкой».
> Обратите внимание, вы только что стали php разработчиком. Потому, что получили деньги за работу с php.
> А потом люди удивляются откуда о php разработчиках предвзятое мнение.
Ну как сказать… вот Libre Office написан на C++. Означает ли скачивание этого пакета и создание документов в нем то, что вы стали разработчиком С++?
WordPress — это прикладное приложение, среда для быстрой разработки сайтов вообще без навыков веб-разработки. Конечно же, зная PHP и JavaScript, вы можете делать сайты в ней лучше, преодолевать ограничения тем и самой среды, но прелесть WordPress как раз в том, что это знание опциональное, а не обязательное. И это опять ответ на ваш вопрос:
> Что такого особенного в связке LAMP+WordPress
И это что, какая-то уникальная фишка Wordpress и того, что он написан на PHP? Может быть Wordpress действительно в этом неплох, но я могу ровно тоже самое сделать и на другой платформе.
А PHP тут как-то вообще не причем.
А PHP тут как-то вообще не причем.
Честое слово, детский сад какой-то. Что автор вообще хотел сказать? «Пожалуйста, не критикуйте больше мой любимый язык, потому что мне от этого грустно и обидно»?
«После такого задаешься вопросом — а не выбрал ли я плохой язык?»
И каков ответ? Или такой шквал критики на PHP вы оправдываете тем, что он такой популярный, а другим завидно?
«После такого задаешься вопросом — а не выбрал ли я плохой язык?»
И каков ответ? Или такой шквал критики на PHP вы оправдываете тем, что он такой популярный, а другим завидно?
Кстати, вполне вписывается :) 81.6% всех веб-проектов бегает под ним. Работы на менее популярных языках меньше. Обидно! :)
Не обидно, потому что на других языках задачи обычно гораздо интереснее, а спрос не сильно меньший (в пересчете на к-во владеющих языком).
Ну как это не обидно, если такая реакция? PHP-шники недопрограммисты заняли рынок и отбивают работу у крутых адептов языка X, не?
Да никто не отбирает работу, успокойтесь. Прямо сплю и вижу, как пхапешники вымрут, и я наконец смогу клепать блоги и интернет магазины на PyWordPress и PyJoomla. Но наступает утро, и я c унынием иду писать асихронные сервера на python, которые держат тысячи соединений на процесс и успевают еще делать machine learning. Аж зубы от злости сводит, ага.
Я думаю, стоит также добавить, что автор статьи всю свою професиональную жизнь писал только на PHP и Javascript. Выводы, что называется, делайте сами.
По поводу concurrency в PHP:
'Parallel PHP' намечается в следующих релизах (возможно 8).
Multi-threading в PHP возможно использовать уже сейчас с pthreads:
Также есть non-blocking concurrency framework Amp
'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);
}
}
?>
Также есть non-blocking concurrency framework Amp
$LovePhp
$phpIsHTMLtemplate
И его синтаксис, особенно создание переменных.
$phpIsHTMLtemplate
И его синтаксис, особенно создание переменных.
Слушайте, тенденция брать статьи, переводить, даже забыв про копирайт, и публиковать, тупо внизу написал что угодно про свою компанию — она прямо вымораживает мозг. Конечно, важно взять больную тему, такую, чтобы побольше комментов было.
Рецепт прост: платим за аккаунт, и на наши похождения никто криво уже не посмотрит. Публикуем что угодно, лишь бы собрать аудиторию. В конец пишем любую ересь, но со ссылкой про себя.
Помните, как в анекдоте: «Это рыба, и шерсти у нее нет. Но если бы шерсть была, то в ней жили бы блохи — и далее про блох».
Не стыдно за (видимо, когда-то любимый) ресурс, товарищи платноаккаунтщики?
P.S. А ссылку на оригинал и указание «перевод» — этому вас не учили, профи от мира электронных платежей («проекта который, поможет подключить вам на сайте прием платежей или массовые выплаты» — хоть Word натравите на фразу, чтобы запятые расставить)?
Рецепт прост: платим за аккаунт, и на наши похождения никто криво уже не посмотрит. Публикуем что угодно, лишь бы собрать аудиторию. В конец пишем любую ересь, но со ссылкой про себя.
Помните, как в анекдоте: «Это рыба, и шерсти у нее нет. Но если бы шерсть была, то в ней жили бы блохи — и далее про блох».
Не стыдно за (видимо, когда-то любимый) ресурс, товарищи платноаккаунтщики?
P.S. А ссылку на оригинал и указание «перевод» — этому вас не учили, профи от мира электронных платежей («проекта который, поможет подключить вам на сайте прием платежей или массовые выплаты» — хоть Word натравите на фразу, чтобы запятые расставить)?
Утверждаете, что Хабр любимый ресурс, но пользоваться им не умеете. Объясняю:
Вот сюда кликаешь и попадешь на источник, это не мы придумали, так устроен якобы любимый вами ресурс. Хотя судя по вашему профилю любовь у вас не взаимная.
Вот сюда кликаешь и попадешь на источник, это не мы придумали, так устроен якобы любимый вами ресурс. Хотя судя по вашему профилю любовь у вас не взаимная.
Вообще, если вы читаете внимательно, где во фразе
> Не стыдно за (видимо, когда-то любимый) ресурс, товарищи платноаккаунтщики?
упоминается моя любовь к ресурсу? :) Я как раз и не очень рад, что очередной холиварной текстовкой откровенно привлекают внимание к сайту компании. А насчет ссылки на оригинал — да, она не сказать чтобы бросается в глаза, это так. После очередной «удачной» смены дизайна не всегда легко найти привычные элементы.
Но вернемся к основной моей мысли. Мы с вами без труда придумаем еще десяток отличных холиварных тем, для продолжения пиара веб-пеймента. Скажем, «а я ушел с линукса на винду, потому что я так привык, и не надо мне тыкать, что я не профи», «оказывается, апач — не единственный веб-сервер», «безопасность придумали трусы, просто надо хранить данные в куках зашированными» и прочее. Нужен ли нам хабр с таким подходом к наполнению? Не думаю. Назвать ли его, наполняемого таким образом, «любимым» мною (как вы мне приписали)? Хм, это определенно не тот по духу ресурс, которым он был в начале.
Хорошо, а вы-то сами как относитесь к логике «ссылки не пахнут»?
> Не стыдно за (видимо, когда-то любимый) ресурс, товарищи платноаккаунтщики?
упоминается моя любовь к ресурсу? :) Я как раз и не очень рад, что очередной холиварной текстовкой откровенно привлекают внимание к сайту компании. А насчет ссылки на оригинал — да, она не сказать чтобы бросается в глаза, это так. После очередной «удачной» смены дизайна не всегда легко найти привычные элементы.
Но вернемся к основной моей мысли. Мы с вами без труда придумаем еще десяток отличных холиварных тем, для продолжения пиара веб-пеймента. Скажем, «а я ушел с линукса на винду, потому что я так привык, и не надо мне тыкать, что я не профи», «оказывается, апач — не единственный веб-сервер», «безопасность придумали трусы, просто надо хранить данные в куках зашированными» и прочее. Нужен ли нам хабр с таким подходом к наполнению? Не думаю. Назвать ли его, наполняемого таким образом, «любимым» мною (как вы мне приписали)? Хм, это определенно не тот по духу ресурс, которым он был в начале.
Хорошо, а вы-то сами как относитесь к логике «ссылки не пахнут»?
Дополняя cigulev: возле названия статьи справа метка «перевод».
Одна из первых причин, которая многих раздражает вполне конкретна — PHP — динамические типы данных.
Ссылка на хабр же: http://habrahabr.ru/post/259497/
И это усложняет разработку, это усложняет изучение языка. Это чаще заставляет пользоваться справочником PHP, иногда посматривать в историю версий, так как многое запоминать не хлочется. То, что PHP для начинающих, — это, возможно, все же миф.
Замечу еще, что на php написана хорошая доля бразуерных игр, многие из которых очень даже успешные коммерческие проекты.
Еще один жирный + языка возможность очень быстро развернуть почти на всем какую-старую версию языка, если надо потестировать или изучить функционал какого-то старого движка. Не спешите кричать «а зачем оно надо?». Мне попался игровой движок, который начинал писаться лет 10 назад, писался явно разными программистами, тут закомментированный императивный код, вместо него ООП, смесь и того и другого. Движок для версии 5.2. Три дня работы, нет не мучений, именно работы и я запустил его на версии 5.6.
Еще один + — для браузерных динамических масштабируемых игровых проектов PHP почти идеален.
Спасибо. Вот теперь пинайте.
Ссылка на хабр же: http://habrahabr.ru/post/259497/
И это усложняет разработку, это усложняет изучение языка. Это чаще заставляет пользоваться справочником PHP, иногда посматривать в историю версий, так как многое запоминать не хлочется. То, что PHP для начинающих, — это, возможно, все же миф.
Замечу еще, что на php написана хорошая доля бразуерных игр, многие из которых очень даже успешные коммерческие проекты.
Еще один жирный + языка возможность очень быстро развернуть почти на всем какую-старую версию языка, если надо потестировать или изучить функционал какого-то старого движка. Не спешите кричать «а зачем оно надо?». Мне попался игровой движок, который начинал писаться лет 10 назад, писался явно разными программистами, тут закомментированный императивный код, вместо него ООП, смесь и того и другого. Движок для версии 5.2. Три дня работы, нет не мучений, именно работы и я запустил его на версии 5.6.
Еще один + — для браузерных динамических масштабируемых игровых проектов PHP почти идеален.
Спасибо. Вот теперь пинайте.
И это усложняет разработку, это усложняет изучение языка.
изучение языка оно не усложняет, оно увеличивает возможность накосячить.
в целом возможно вам будет интересно что в PHP7 можно писать так:
function foo(string $bar) : string {
return str_replace('bar', 'foo', $bar);
}
1. Мне без разницы мнение каких-то личностей о профессиональном инструменте, благодаря которому у меня нет проблем с поиском работы и достойным вознаграждением.
2. PHP меня полностью устраивает своими возможностями и темпами развития.
О чём еще можно разговаривать тогда с хейтерами?
2. PHP меня полностью устраивает своими возможностями и темпами развития.
О чём еще можно разговаривать тогда с хейтерами?
Haters gona hate
О недостатках php. Если вас всё устраивает в каком-нибудь языке программирования это скорее всего означает, что вы на нём не программируете :). С темпами развития, да прикольно. Можно расти вместе с языком.
Есть разница между «устраивает возможностями» (хотя лично мне многого не хватает «из коробки») и «всем устраивает».
Я бы сказал, что если меня устраивает язык программирования, значит я делаю на нём то, для чего он предназначен. В данном случае классические веб-сервисы и иногда демоны с асинхронной работой. И не использую php например для системного скриптинга или для десктопных приложений.
А синтаксис — дело привычки, но php и не многословен по сравнению с некоторыми иными.
А синтаксис — дело привычки, но php и не многословен по сравнению с некоторыми иными.
Если человек очень много ругает язык программирования, скорее всего, он просто этот язык программирования не осилил.
Очень хорошо язык знают те люди, которые его разрабатывали, а они его ругать не будут.
Что значит знают хорошо? И что ругают? Синтаксис языка? Он прекрасен.Понятен и очень прост.
Логику языка? Это пустое и странное занятие.
Что ругать? Сам интерпретатор? То как он работает? Это тоже странно, с учётом того, что в исходники, скорее всего за все время существования php, смотрели только разработчики.
Что ругать в итоге?
Код, который пишут новички и непрофессионалы?
Про новичков — никто пока не начал программировать, только появившись из утробы матери.
Про непрофессионалов — это явление вечное.
И где та тонкая грань между профи и непрофи?
Ругань php остается списать на антипропаганду достаточно открытой технологии.
Что значит знают хорошо? И что ругают? Синтаксис языка? Он прекрасен.Понятен и очень прост.
Логику языка? Это пустое и странное занятие.
Что ругать? Сам интерпретатор? То как он работает? Это тоже странно, с учётом того, что в исходники, скорее всего за все время существования php, смотрели только разработчики.
Что ругать в итоге?
Код, который пишут новички и непрофессионалы?
Про новичков — никто пока не начал программировать, только появившись из утробы матери.
Про непрофессионалов — это явление вечное.
И где та тонкая грань между профи и непрофи?
Ругань php остается списать на антипропаганду достаточно открытой технологии.
Причины ругать всегда есть. Я не претендую на звание знатока РНР, но даже я могу невооруженным взгядом видеть проблемы. Синтаксис РНР прекрасен? Нет, не прекрасен. Он имеет как минимум один жуткий косяк в виде отсутствия строгой типизации. Ругать интерпретатор тоже есть за что. Как он внутри работает, я… ну скажем так, заглядывал в конце 2000-х. После распутывания макросов С++ где-то на седьмом уровне вложенности осознал, что разработчики — нездоровые фрики, и развивать ЭТО можно только полным переписыванием с нуля. И вероятно отсюда вытекает и внешний недостаток интерпретатора, это отсутствие нормальной совместимости между версиями. Кстати, и открытость тоже тут становится неактуальной. Ну не будет никто в нем править баги…
Как у вас получается соотносить синтаксис и строгую типизацию?
Это две абсолютно не связанные вещи. Строгая типизация это не признак синтаксиса, это признак языка.
По поводу кода, PHP написан на C, откуда там макросы из C++? На плюсах можно только расширения писать, но не основной код языка PHP.
Это две абсолютно не связанные вещи. Строгая типизация это не признак синтаксиса, это признак языка.
По поводу кода, PHP написан на C, откуда там макросы из C++? На плюсах можно только расширения писать, но не основной код языка PHP.
Синтаксис РНР прекрасен? Нет, не прекрасен. Он имеет как минимум один жуткий косяк в виде отсутствия строгой типизации.
1) синтаксис вменяем (сравните с bash или perl, хотя и тут найдутся не согласные, это весьма субъективная оценка).
2) строгая типизация никакого отношения к синтаксису не имеет, и это сомнительный плюс (ну то есть это клево но пораждает свои проблемы, и учитывая особенность сферы применения php — на пользу это никому не пойдет). Есть тайп хинтинг (в том числе и для скаляров и для возвращаемых значений), возможно вскоре появится тайпхинтинг для свойств объектов и т.д. (в Hack например).
Как он внутри работает, я… ну скажем так, заглядывал в конце 2000-х.
И что вы там ругать собрались? Примитивная виртуальная машина (каждому опкоду соответствует просто какая-то функция виртуальной машины, так все интерпритаторы устроены), с php7 вместо кастыльного парсера у нас уже адекватный парсер использующий промежуточное представление (абстрактное синтаксическое дерево). Словом… я в коде PHP конечно странные места находил, но видал и похуже.
Ну и опять же, за последние лет 5 много чего сделали. Самые большие изменения в нутрах PHP произошли с выходом PHP 5.4, там множество оптимизаций было внедрено.
После распутывания макросов С++ где-то на седьмом уровне вложенности
макросы это чисто сишная штука, и чисто для упрощения разбора кода. Вы видимо не смотрели исходники CPython, Ruby MRI и т.д. Из сишных проектов которые мне довелось смотреть только постгрес может показаться идеальным.
ЭТО можно только полным переписыванием с нуля
FYI в php 7 все внутренние структуры используемые для рантайма были переделаны, почти все ядро переписано.
это отсутствие нормальной совместимости между версиями
вы о чем вообще? нет никаких проблем с совместимостью между версиями.
вобщем резюмирую, вы видимо вообще не представляете о чем говорите. Либо вас переполняют эмоции а это опять же говорит о том что объективно оценивать что там так или не так или нужно переписывать вы не можете.
> Как у вас получается соотносить синтаксис и строгую типизацию?
Вы хотите сказать, что правила определения типов данных не является частью синтаксиса языка? Браво.
> Ну и опять же, за последние лет 5 много чего сделали.
Я рад за ваш прогресс. Если бы вы не вскипели благоверной яростью за любимую игрушку после первых четырех слов, то увидели бы дальше по тексту, я там написал, что смотрел исходники PHP в конце 2000-х, и что я не являюсь экспертом по РНР.
> макросы это чисто сишная штука, и чисто для упрощения разбора кода.
Да вы что? А я-то думал, что макросы в сишных исходниках пхп — это не сишная штука :) Так, к сведению, многкратная вложенность макросов в коде — это для усложнения разбора кода.
> вы о чем вообще? нет никаких проблем с совместимостью между версиями.
Странно. А чего тогда переписывали сайты с версии 4 на 5?
> вобщем резюмирую, вы видимо вообще не представляете о чем говорите. Либо вас переполняют эмоции
В общем, резюмирую: я задел ваш любимый проект, и вы тут же расчехлили свой какашкомёт и кинулись в холивар. Угомонитесь. Я не собираюсь ни ругать, ни хвалить пхп. Я им уже давным-давно не пользуюсь, и особо и не наблюдаю за его прогрессом. Я просто привел предыдущему оратору пример, почему не надо бездумно хвалить технологии, при этом подчеркнув, что моя информация — семилетней давности. Не более того.
Вы хотите сказать, что правила определения типов данных не является частью синтаксиса языка? Браво.
> Ну и опять же, за последние лет 5 много чего сделали.
Я рад за ваш прогресс. Если бы вы не вскипели благоверной яростью за любимую игрушку после первых четырех слов, то увидели бы дальше по тексту, я там написал, что смотрел исходники PHP в конце 2000-х, и что я не являюсь экспертом по РНР.
> макросы это чисто сишная штука, и чисто для упрощения разбора кода.
Да вы что? А я-то думал, что макросы в сишных исходниках пхп — это не сишная штука :) Так, к сведению, многкратная вложенность макросов в коде — это для усложнения разбора кода.
> вы о чем вообще? нет никаких проблем с совместимостью между версиями.
Странно. А чего тогда переписывали сайты с версии 4 на 5?
> вобщем резюмирую, вы видимо вообще не представляете о чем говорите. Либо вас переполняют эмоции
В общем, резюмирую: я задел ваш любимый проект, и вы тут же расчехлили свой какашкомёт и кинулись в холивар. Угомонитесь. Я не собираюсь ни ругать, ни хвалить пхп. Я им уже давным-давно не пользуюсь, и особо и не наблюдаю за его прогрессом. Я просто привел предыдущему оратору пример, почему не надо бездумно хвалить технологии, при этом подчеркнув, что моя информация — семилетней давности. Не более того.
не является частью синтаксиса языка? Браво.
Нет, я хочу сказать что вы подменяете понятия. Синтаксис языка это вообще весьма вторичная штука, в то время как система типов это уже интереснее. А вопрос статическая/динамическая типизация это холивар которому уже лет 20.
PHP в конце 2000-х, и что я не являюсь экспертом по РНР.
Вот этот фрагмент который вы процетировали я как раз по этому поводу и описал.
это не сишная штука :)
вы сказали что это C++ ные штуки, есть разница
это для усложнения разбора кода.
FYI это позволяет нехило так DRY-ит код, упрощать его и т.д. Хэндлить такие нюансы как различия с big/little endians, и куча других вещей. В Си подругому как-то не особо получается писать и так написаны почти все проекты на Си. Возможно 7 лет назад код PHP был намного хуже, я не спорю, но думаю что примерно так же. Как никак Расмус и его други Сишники. А проблема PHP в том что изначально его не проектировали как язык программирования.
Странно. А чего тогда переписывали сайты с версии 4 на 5?
Потому что между php4 и php5 разница существенна, но не настолько существенна как между python2 и python3. Так что… все относительно. Да и на тот момент небыло таких инструментов как php-parser и т.д.
я задел ваш любимый проект, и вы тут же расчехлили свой какашкомёт и кинулись в холивар.
вы сдедали вброс, я прокоментировал.
почему не надо бездумно хвалить технологии
Так а кто-то хвалит?) Я против как хэйта так и нахваливания так как в этом всем нет ни капли объективности как правило. В целом же именно с этой мыслью я полностью с вами согласен.
> Нет, я хочу сказать что вы подменяете понятия. Синтаксис языка это вообще весьма вторичная штука,
> в то время как система типов это уже интереснее.
Если вы решили углубиться в детали, то «система типов» — это их состав, организация и размерность. Правила описания типов и собственно их наличие — это синтаксис в чистом виде.
> вы сказали что это C++ ные штуки, есть разница
Вы знаете, если вы пишете код на С++ и используете там что-то, что понимает препроцессор компилятора С++, то это часть языка С++. Даже если она туда перекочевала ранее из языка С.
> FYI это позволяет нехило так DRY-ит код, упрощать его и т.д.
… если использовать с умом. Все языковые конструкции существуют исключительно из чьих-то благих намерений сделать лучше, упрощать и т.д. Проблемы возникают с теми, кто их использует коряво. Нет ничего плохого в макросе, макрос — это хорошо. Но когда макрос использует макрос, а тот макрос использует другой макрос, а другой еще, и продолжите цепочку несколько раз… это не упрощение кода. Это программист, у которого увлечение абстракциями затоптало здравый рассудок.
> Потому что между php4 и php5 разница существенна
Ок. Теперь давайте назовём это проблемой с совместимостью между 4 и 5 версиями, ладно? ;)
> в то время как система типов это уже интереснее.
Если вы решили углубиться в детали, то «система типов» — это их состав, организация и размерность. Правила описания типов и собственно их наличие — это синтаксис в чистом виде.
> вы сказали что это C++ ные штуки, есть разница
Вы знаете, если вы пишете код на С++ и используете там что-то, что понимает препроцессор компилятора С++, то это часть языка С++. Даже если она туда перекочевала ранее из языка С.
> FYI это позволяет нехило так DRY-ит код, упрощать его и т.д.
… если использовать с умом. Все языковые конструкции существуют исключительно из чьих-то благих намерений сделать лучше, упрощать и т.д. Проблемы возникают с теми, кто их использует коряво. Нет ничего плохого в макросе, макрос — это хорошо. Но когда макрос использует макрос, а тот макрос использует другой макрос, а другой еще, и продолжите цепочку несколько раз… это не упрощение кода. Это программист, у которого увлечение абстракциями затоптало здравый рассудок.
> Потому что между php4 и php5 разница существенна
Ок. Теперь давайте назовём это проблемой с совместимостью между 4 и 5 версиями, ладно? ;)
Даже если она туда перекочевала ранее из языка С.
Никуда оно не перекочовывало, оно написано на Си и собирается через gcc (а не g++). Тот факт что вы можете собрать php через компиляторы C++ является лишь следствием совместимости C++ и Си. В прочем это на самом деле все не столь важно. Мне было просто любопытно почему C++.
Это программист, у которого увлечение абстракциями затоптало здравый рассудок.
Ну я сейчас сходу не смогу вспомнить где там что-то такое есть, а то что я видел в принципе нормально коррелировалось со всем этим. Вместо макросов там можно было использовать просто функции, но только производительности ради нужно было просто заинлайнить это дело + упростить код что бы уменьшить количество проблем связанных с совместимостью между разными платформами.
проблемой с совместимостью между 4 и 5 версиями, ладно? ;)
Ну это не проблема, именно из-за нарушения обратной совместимости (не так уж и глобально) это мажерный апдейт (семвер все-таки). Оно всегда проблема обновляться на мажерный релиз. Python2 и Python3 вообще не шибко совместим оказался и народ лет 5 перебирался. И им норм.
1) синтаксис вменяем (сравните с bash или perl, хотя и тут найдутся не согласные, это весьма субъективная оценка).
Верное замечание. Всегда надо сравнивать языки в рамках одной и той же категории. Действительно, чего сравнивать с java то, что больше похоже на bash. Думаю надо пойти дальше. Думаю надо сравнить с brainfuck. Логика в общим понятна. Аутсайдеров надо сравнивать с другими аутсайдерами, а не с лучшими представителями области.
2) строгая типизация никакого отношения к синтаксису не имеет
Внезапно.
и это сомнительный плюс
О как. Ну с точки зрения тех, кто этой типизацией не пользуется, может и правда сомнительный.
(ну то есть это клево но пораждает свои проблемы, и учитывая особенность сферы применения php — на пользу это никому не пойдет).
Вы видимо хотите сказать, что задачи, стоящие перед php разработчиками настолько примитивны, что строгая типизация погоды не сделает?
Я хочу сказать что тайп хинтинг решает почти все проблемы возникающие в следствии динамической типизации. Тут вам и статический анализ, и многое другое. С другой стороны динамическая система типов позволяет не сильно замарачиваться внутри и позволяет быстрее писать простой код (коего на php пишется сегодня подавляющее большинство). А так, с тех пор как появился тайп хинтинг для скаларов и режим строгого соответствия типов для аргументов (не по умолчанию), думаю проблем станет чуть меньше.
Хотя справедливости ради даже на момент php7 тайп хинтинг не покрывает все так что бы можно было на 100% вычислить типы всего и вся используемые, но может быть в 7.1 (или рядом) сделают дженерики и жизнь улучшится. В целом я подозреваю что в итоге будет точно так же как в Hack.
Хотя справедливости ради даже на момент php7 тайп хинтинг не покрывает все так что бы можно было на 100% вычислить типы всего и вся используемые, но может быть в 7.1 (или рядом) сделают дженерики и жизнь улучшится. В целом я подозреваю что в итоге будет точно так же как в Hack.
Тайп хинтинг — хорошо конечно. Но система статической типизации конечно лучше.
А можно пример кода, который будет проще, если использовать динамическую систему типизации? Я такого придумать не могу чего-то.
С другой стороны динамическая система типов позволяет не сильно замарачиваться внутри и позволяет быстрее писать простой код (коего на php пишется сегодня подавляющее большинство).
А можно пример кода, который будет проще, если использовать динамическую систему типизации? Я такого придумать не могу чего-то.
Я такого придумать не могу чего-то.
Я если честно тоже, потому что не люблю так писать) у меня переменные обычно сохраняют свой тип (я даже менять их не люблю). Но даже в C++ уже никто явно типы не описывает и оставляет это дело компилятору вычислять (спецификатор auto).
Я пожалуй все же хотел сконцентрировать внимание что с динамической системой типов нет необходимости парится о том какого типа переменная в данный момент времени. А если у нас код локализован в функциях/методах объектов c тайп хинтингом, и эти функции маленькие, то вычислить типы не представляется проблемой.
Ну то есть для обучения это одновременно и плюс и минус. С одной стороны мы не загружаем людей всякой ересью (вроде теории категорий) и позволяем быстрее писать код (не забывайте что большинство php разработчиков делают всякие там бложики да лэндинги, со всякими wordpress и joomla, стоимость разработки подобного резко бы подскачила вверх в случае усложнения языка и увеличения уровня необходимых знаний). Но с другой стороны тайп хинтинг (правда не будем лукавить, все ок только в PHP7 и то не совсем) решает проблемы для другой категории PHP разработчиков которые пишут серьезные приложеньки, хотя бы от уровня интернет магазина.
То есть сложность инструмента обычно все же коррелируется со сложностью задачи, которую мы пытаемся этим инструментом решить.
Никогда не смогу для себя ответить на след. вопрос: где все ругатели, когда технология только появляется?
А большинство ругателей 20 лет назад писали статичные сайты на html и не мечтали о чем-то большем.
А большинство ругателей 20 лет назад писали статичные сайты на html и не мечтали о чем-то большем.
Вы предлагаете ставить памятник всем технологиям только за то, что они появились? Вроде как нас бесплатно облагодетельствовали, и все должны радостно и молча кушать то, что дают? :)
молча кушать то, что дают? :)
нет конечно, но сегодня это скорее «громко возмущаться и кушать то, что дают». То есть никто даже не пытается разобраться с проблемой, предложить конструктивные решения и т.д. Обсудить их в php internals и т.д. Опенсурс же. Если идея неплохая то ее даже кто-нибудь и реализует.
Но это же так сложно, отнимает много времени и т.д. так что проще просто продолжать возмущаться в комментах и продолжать кушать что дают, или же есть что-то другое, и всеравно ругаться.
100 лет назад мужик ездил на телеге, у которой не было амортизации, представляешь? Как-то ездил и эта телега его кормила. Через 80 лет другой мужик ехал на машине марки Москвич и ругал эту машину.
Десять лет машина без гидроусилитея — дрянь. 5 лет назад, как же мне прожить без коробки автомат7
Наше время, в машине есть, кроме пологрева одного места ( по которому надо бы бить чаще) и опять дрянь.
Из-за разного рода придурков, которые мнят себя гениями, а на деле ни хрена сделать не могут, кроме как скопировать, нормальные люди с очень большим подозрением начинают относится к PHP, да и вообще к программированию… Умерьте свою гордость… свое нахрен никому тут не нужное ехидство… Не нравится PHP, пишите на чем нравится… Зачем вообще лезть в эту ветку?!
Десять лет машина без гидроусилитея — дрянь. 5 лет назад, как же мне прожить без коробки автомат7
Наше время, в машине есть, кроме пологрева одного места ( по которому надо бы бить чаще) и опять дрянь.
Из-за разного рода придурков, которые мнят себя гениями, а на деле ни хрена сделать не могут, кроме как скопировать, нормальные люди с очень большим подозрением начинают относится к PHP, да и вообще к программированию… Умерьте свою гордость… свое нахрен никому тут не нужное ехидство… Не нравится PHP, пишите на чем нравится… Зачем вообще лезть в эту ветку?!
Полагаю, проблема как с «придурками, которые мнят себя гениями», и которые всё портят, так и с пострадавшими от них несчастными «нормальными людьми» надумана. Никто ни от кого не пострадал.
Но если бы не было людей, недовольных телегами, вы бы и сейчас ездили на телегах. Или ещё того хуже, на машинах марки «Москвич». Как раз критика и недовольные люди двигают вперёд прогресс.
> Не нравится PHP, пишите на чем нравится
Спасибо за совет
> Зачем вообще лезть в эту ветку?!
Это же ваш личный комментарий. Вы его хозяин, поэтому просто удалите мой пост.
Но если бы не было людей, недовольных телегами, вы бы и сейчас ездили на телегах. Или ещё того хуже, на машинах марки «Москвич». Как раз критика и недовольные люди двигают вперёд прогресс.
> Не нравится PHP, пишите на чем нравится
Спасибо за совет
> Зачем вообще лезть в эту ветку?!
Это же ваш личный комментарий. Вы его хозяин, поэтому просто удалите мой пост.
Зачем вообще лезть в эту ветку?!
Ну, очевидно для того, чтобы ответить на вопрос где все ругатели, когда технология только появляется.
Жизнь PHP-разработчика