Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Какой язык программирования лучше выбрать — PHP или Ruby для первой работы?

Честно мне больше по душе Ruby, но я слышал там меньше вакансии, и не такая лояльность к новичкам как на PHP.

За большой зарплатой не гонюсь, мне самое главное получить профессиональную практику и умения. Так что лучше выбрать PHP или Ruby?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Аксиома Эскобара

Я бы посоветовал PHP. Все что там пишут что типа болото, бред. Вакансий куча постоянно, и в больший компаниях есть вакансии php разработчиков, с большим уклоном на symfony. Средние конторки используют Laravel, Yii2 и т.д.. А также CMS, но почему плохо? Тоже хватает вакансий, тот же WP или Drupal. Да, зарплаты не большые, но возможно подрабатывать на upwork например.

Не-не-не, только не wp и друпал.
Если уж чему-то научиться, то стоит начинать с symfony или хотя бы с laravel.

А вообще лучше сразу задуматься о Java / С#

Можно подумать сейчас говнокодеров в джаве не хватает? Сейчас большинство начинает изучать java не за сам язык (его мощь), а только из-за картинок как круто работать в больших IT компаниях и зарабатывать >$1500.

Так в php уже никто и не идёт, все в джаву / qa табунами ломятся. А, ещё в js, да

Та ну, откуда такая инфа? что в php никто не идет

Исключительно субъективное, по количеству курсов, тренингов, тем на форумах, общему хайпу. Уже каждая уборщица знает что нужно учить английский и джаву, идти в циклумы, епамы и прочие софт-сервы, играть в теннис, наяривать кофеи и посидеть 3 часа в иде, а то от работы кони дохнут.

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

Ну так если вакансий пусть 10 а «НЕ» идиотов пришло 30, куда 20 девается? Правильно. В лет 30-40 начинают изучать PHP что бы хоть как то со своего «Хочу в IT» заработать денег.

На подобие этого где то в сети есть старый видео ролик, только там java против c#.

На java и c# нужно родиться senior-ом))) Ну если выплывет вакансия джуна раз в три-четыре месяца где-то в одной конторе. На эту одну вакансию очередь как очередь на квартиру)))

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

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

Кто-то ж должен унылое легаси разгребать )

Подскажите пожалуйста хостинг для PHP.

Лучше с git встроенным.

Любой vps, хоть digital ocean, хоть ещё что-то

Именно, и ставить что хочется.
Несколько команд, чуток подправить конфиги и готово. Ну или docker engine и загружать готовые имеджи с уже настроенным приложением.

Насчет перспективности Ruby есть свежая статья с Хабра habr.com/post/433672

Просто залишу це тут : «Почти каждый уважающий себя рубист уходит на Golang. Так что ответ очевиден.» ;)))

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

Дело ваше. Я мог бы сейчас писать на PHP, получать свои скромные 1500 и не париться. Но мне нравиться Go. Я не привык делать то что мне не нравится...

А мне нравится Ruby, Crystal, Swift, но последний так себе )

Я сам php — кодер, если что))

Цитатко из статьи: «Когда эта технология имеет строгую типизацию, что является плюсом к надежности — это еще один камень в огород Ruby». Кажецца, кто-то плохо понимает смысл слов, которые использует...

А фронт почему откидываете? JS всегда востребован

PHP (только без CMS) или JS

Решать вам, но если бы у меня была возможность вернуться назад, то начинать с PHP я уж точно бы не стал...

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

Ruby мені подобається значно більше.. Але якщо щодо перспективи, то міг би порадити Python, як першу мову... Та й сфера застосування значно ширша..

Да на официальном сайте руби, так и пишется «Ruby друг программиста» я думаю и руби тоже расширится дело времени, или придет альтернатива кристал.

Есть еще Python (Django, Flask) и JavaScript (Node.js + Express.js). А также разные сишарпы с ASP.NET-ами.

Но если нравится руби, то почему не руби? :-)
Ибо неважно, сколько вакансий, главное, чтобы они были, и чтобы ты достаточно неплохо шарил(а) в рубях/рельсах, чтобы тебя взяли. ;-)

В Украине он не пользуется таким спросом, как PHP, судя по статистике.
jobs.dou.ua/...​rends/categories/2018-11

Однако и анкет в два раза меньше.

Скорее всего пхп сеньоры просто есть и во всяких херсонах и полтавах (никого не хочу обидеть), а вот питонщики в миллионниках тусят.

Пхп разное бывает. На вордпресс/джумла зарплаты одни , на симфони/ларавел другие. В статистике все зарплаты в куче.

Среди пхп анкет полно людей из вебстудий, где делают проекты на CMS. В пайтоне CMS работ нет, все работы — нормальные. В PHP-мире CMS-девелоперов больше, чем тех, кто делает проекты на дорогих фреймворках. Это приводит к падению среднего значения пхп-зарплаты (проекты на CMS — дешевле). Фреймворки и CMS — два разных мира, их нужно разделить, как разделяют даже конференции по PHP — на конференции по фреймворкам (fwdays) и конференции по CMS (drupalcamp, wordpress kitchen). Если бы была статистика по отдельно php-фреймворк синьерам, то было бы наглядно видно, что их количественно столько же, сколько пайтон девелоперов и что зарплаты там плюс-минус такие же.

Поэтому никто никуда не скатывается и не буксует. Среди симфонистов зарплаты только растут каждый год. Найти синьера за $3k с опытом симфони в несколько лет — это проблема. Хотят 3,5-4k. Не думаю, что питонисты дороже.

А все потому что у пыхи есть спринг-лайк фреймворк и она серьезно поддала в производительности на версии 7. И до сих пор каждая минорная 7.1, 7.2, вот уже 7.3 дают прироста по 15-30% производительности, а это то, что нужно рынку.

Понятно что пятая серьезно уступала всем, а четвертая до того — вообще не язык, а дерьмище процедурное. Хреновая репутация за годы накопилась, да, но сейчас она постепенно отмывается, начиная с семёрки. И становится всё лучше и лучше. Грех говорить, что скатывается.

А зачем равняться на конкретные страны, в наше время информационных технологий думаю стоит обращать внимание на всемирную статистику 😕

А есть аналогичная статистика соотношения вакансий и откликов на них в международных масштабах?

Так работать то скорей всего (какое то время) придется на галере в нашей стране :) поэтому и равняются по статистике Украины

1) 0 сообщение
2) 1 топик на холиварную тему
3) абсолютная безучастность в обсуждении топика
4) отсутствие каких-либо подключенных соц.сетей и отсутствие фотки.

Все категории указывающие на то, что это не фейк созданный админами для накрутки активности на сайте, а человек нуждающийся в моем совете. Поэтому напишу:

***Длинный комментарий сравнения языков, примеры альтернатив и пара примеров из собственного опыта***

С появлением «участности» я бы предположил, что автор а) доцент и на кафедре біли две книги по Руби и ПХП б) девятикласник, у которого два соседа пхпист и рубист. Сорь, автор -)

Сомнительная у него активность, состоящая из фраз из заголовка топика.

Вот только если после этого коммента начнет красноречиво изъясняться будет вообще палевно.

Админы ДОУ не создают такие фейки, создают топики со своих аккаунтов, например:
dou.ua/users/CB/topics

Вас понял. Спасибо, что прояснили ситуацию.
В любом случае что это фейк со странной мотивацией сомнений не остается.

На форуме ДОУ в отличие от ленты нет ограничений на то, что писать могут только подтвержденные аккаунты (с именами, LinkedIn-ами и т.п).

Ruby.
Там в среднем требования выше, но:
— сообщество куда более квалифицированное и адекватное
— в среднем уровень проектов выше
— среднее количество паршивости (прежде среди проектов и пакетов) куда ниже

И сам язык — куда приятнее.

Согласен, ruby приятнее для души, но найти работу сложней на нем и лояльности меньше, для новичков.

Жарт про English вже був?

Коментар порушує правила спільноти і видалений модераторами.

Напоминает ситуацию с двумя стульями. Оба языка не самых современных и в которых не хватает тех самых современных фич(а у большинства языков эти фичи связаны с типами). Коли язык не современный велика вероятность нарватся на проект которому много лет, и который писало много человек(leagacy). Leagacy проекты на не-строго типизированных языках программирования очень сложны для восприятия — нет той самой системы типов которая не даст вам в ногу выстрелить. Так что лучше брать что-то новомодненькое и на что вакансии есть.

Leagacy проекты на не-строго типизированных языках программирования очень сложны для восприятия

А легаси на джаве или крестах, надо понимать, пахнет ландышем, а в коде пасутся единороги, какающие бабочками?

Мой месседж:

Так что лучше брать что-то новомодненькое и на что вакансии есть.

Вы его проигнорировали. Типизированное лигаси лучше нетипизированного однозначно, хотя С++ и в некоторых случаях Java с трудом могут называтся типизированными(привет С++ные касты и джавовская рефлексия).

Так что лучше брать что-то новомодненькое и на что вакансии есть.

Огласите весь список, пожалста. А то динамически типизированное низя, олдскул со слабой статической типизацией и кастами тоже, олдскул с сильной статитической типизацией тоже не тру если в рефлексию умеет и так далее... Что остается бедному кодерку вообще? Что такого новомодненького завезли в последние эн лет чтобы оно и ноги отстреливать не давало от слова вообще и вакансии были в количестве, не стремящемся к нулю? Вопрос без двойного дна, просто интересно...

Просто с нестрогой типизацией в «cutting edge» будет тот же уровень, что в шарпе на легаси *trollface*
Поднаброшу на вентилятор: буквально неделю как начал работать с PHP, возникли вопросы по особенностям языка, позвонил знакомым — большая часть вопросов, к моему удивлению, осталась без ответа (смешно, но по идее я сейчас знаю даже больше них и пишу лучше код, если рассматривать только язык). ОК, пусть это мои знакомые, но если зайти на StackOverflow и почитать, как там радостно обсуждают костыли, за которые в приличном обществе руки не подают («как в иерархии A->B->C вызвать конструктор A из C, не вызывая при этом конструктор B»), вместо того, чтобы сразу(!) вправить вопрошающему мозги, то становится понятно, что это средняя температура по палате.
При том, что идёшь в репо github.com/php-fig/fig-standards — хорошие гайдлайны, можно нормальный код писать. Даже в версии 5.6 вполне хватает инструментов, свободно залетают ООП принципы, SOLID, есть анонимные методы и т.д. В следующих версиях подтянули типизацию, и стало вообще ОК. Добавить асинхронность (не в виде промисов и coroutine, а async/await), и практически всё, что нужно, уже было бы.

асинхроность я таки надеюсь не затянут в язык. Это лишняя сложность у приложения которая на самом деле будет продуцировать больше говнокода, а по факту мало кому нужна в реальном веб приложении.

Это лишняя сложность у приложения которая на самом деле будет продуцировать больше говнокода, а по факту мало кому нужна в реальном веб приложении.

Обоснуйте, плз — я, например, со 100% пунктов не согласен, при чём категорически).

Обоснуйте, плз — я, например, со 100% пунктов не согласен, при чём категорически).

Мне лично близок подход который описывался разработчиками Slack https://slack.engineering/taking-php-seriously-cf7a60065329. Особо ничего не добавить и не убрать.
Зачем вводить внутри изолированного процесса еще процессы/треды/стеки мне не понятно, а думать про них тоже надо если уже их затянули в проект.
Я не против всяких asinc/await как таковых или промисов или других вещей, но вот в пхп оно не нужно, а как показывает опыт как только появляется, что-то новое модное-молодежное его обязательно кто-то затянет в проект. Причем подчас самым невменяемым образом.
Можете привести пример когда вам бы понадобилось выполнять какие-то команды в пхп асинхронно ?

Можете привести пример когда вам бы понадобилось выполнять какие-то команды в пхп асинхронно ?

Нюансов именно PHP я не знаю. Асинхронность при правильной готовке повышает производительность сама по себе из-за переиспользования тредов вместо того, чтобы их блокировать. Общие случаи:
1) Fire and forget реквесты.
2) Background таски.
3) Обработка результата асинхронно, т.е. callback’и (а потом callback hell, попытки пофиксить их promise’ами-костылями и т.д.).
Сомневаюсь, что в php их не используют (или используют синхронно).

Нюансов именно PHP я не знаю.

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

1) Fire and forget реквесты.

для этого в php есть curl

2) Background таски.

В случае веба вам надо видеть результат вашего запроса и потому надо синхронно запрос-ответ, а не запрос-ожидание-делаем еще что-то — callback. Если же надо сказать спасибо за ваше сообщение, а дальше тяжелые запросы по разным сервисам то это проще решить сообщением, что ваше сообщение принято и оборвать соединение без убивания самого процесса которой был задействован в обработке запроса. Это работает довольно просто и вся техническая сложность от разработчика скрыта и не засоряет техническими деталями мозг.

3) Обработка результата асинхронно, т.е. callback’и (а потом callback hell, попытки пофиксить их promise’ами-костылями и т.д.).

Это кейс я не совсем понял.

для этого в php есть curl

И Вам нравится, как это реализовано?) Для

это проще решить сообщением, что ваше сообщение принято и оборвать соединение

Уже идёт противоречие с

В случае веба вам надо видеть результат вашего запроса и потому надо синхронно запрос-ответ, а не запрос-ожидание-делаем еще что-то — callback

Если отбросить асинхронность — что в callback’е, что иначе — логика идентично выполнится.

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

Асинхронный POST запрос — это слишком узкое покрытие понятия «асинхронность»). Ну, давайте этот кейс разберём — обрыв после «спасибо» проблему ведь не решает.
1) Отправили запрос -> пришёл синхронно ответ.
2) Сказали спасибо и оборвали соединение (покрывает только Fire and Forget кейс, при чём исключительно в случае HTTP запроса и даже не на уровне языка, а расширения).
3) А теперь — собственно, асинхронность. Обработали ответ, и нам нужно отправить ещё 3 запроса с какой-то инфой, и по каждому ответу, к примеру, что-то записать в базу. При чём, эти запросы и записи не взаимосвязаны напрямую. В таком случае, если не будет даже несчастных callback’ов, вместо 3 запросов одновременно мы будем ждать, пока не выполнятся все 3 по порядку, ещё и пока в базу не запишут ответ. Разница в перформансе будет очевидна.

Это кейс я не совсем понял.

Если у Вас есть только callback’и, то кейс из абзаца выше будет решаться с помощью них. Но ловушка callback’ов в том, что при сложной логике уровень вложенности будет расти, и такой матрёшка-код станет ужасен (если 2 ещё терпимо, то всего 3 callback’а — уже печальная печаль). Чтобы это побороть, придумали promise’ы, которые позволили «облагородить» такой код путём цепочек вызовов. Ну и async/await как полное решение этой проблемы, когда асинхронные методы стали возвращать результат, и синтаксис стал практически повторять синхронный.

Или в PHP реально не бывает кейсов, когда нужно выполнить какие-то действия одновременно? Это не только к Вам вопрос.

Да бывает конечно.
Решается в зависимости от ситуации разными внешними средствами, а не на уровне языка. Что через multi curl, что через добавление задания в очередь (как бы она реализована не была) и пул процессов-воркеров её обрабатывающих.
В общем не всё гладко, не всё хорошо, но как-то работает и приходится с этим мириться )

И Вам нравится, как это реализовано?) Для

Не сильно, но если вдуматься то с промисами оно не сильно то иначе работает.

Уже идёт противоречие с

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

Или в PHP реально не бывает кейсов, когда нужно выполнить какие-то действия одновременно?

Не сказать, что совсем не бывает, но вот описанные ранее случаи это если и не 90 процентов случаев то рискну предположить, что никак не меньше 80. Они покрываются инструментарием за пределами языка. Пусть не идеально, но не настолько плохо, чтоб вводить в язык тред пуллы, промисы или асинк/авейт.

когда вам бы понадобилось выполнять какие-то команды в пхп асинхронно ?

а чем в этом плане пхп отличается от других языков? на пхп пишут какие-то особенные вещи, для которых многозадачность никогда не понадобится?

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

Изи, нужно лезть в 2 разных базы данных и в несколько сторонних сервисов одновременно. потом ответы нужно отдельно орабатывать, и в конце вытащить результат.

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

є сенс лише в частину апу де лонг ранінг

Оно как бэ не для этого нужно...

Для того чтобы все отработало до того как можно будет продолжить работу с данными. Вот наглядный пример plnkr.co/edit/?p=preview

Для того чтобы все отработало до того как можно будет продолжить работу с данными.

В шарпе async не подразумевает await по дефолту, например (т.е., можно и не ждать, пока что-то отработает, а просто заюзать для бэкграунд таска).

Это лишняя сложность

 Не особо то она и сложность если всё разложено по полочкам.

Найскладніше там було зрозуміти діаграму як працює асинхронність в шарпі з async/await

Это не самое сложное. Сложное, это когда есть большое изменяемое состояние(не флоу вида пришёл запрос, мы поработали и выдали ответ, а это самый запрос влияет на состояние всей системы), когда нужно параллелить на n частей, потом состыковывать, когда задача большая и нужно чтобы она не отъедала много памяти. Но и для этого есть решения ( см
typelevel.org/...​-effect/datatypes/io.html
doc.akka.io/...​4/scala/typed-actors.html
doc.akka.io/docs/akka/2.5/stream
)

думати взагалі не приходиться.

Это вы, сударь, зря, думать всегда полезно.

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

Ключевое слово «если». Много вам проектов попадалось, где на код смотришь и думаешь, что вот так бы всегда писали ? Я утверждаю, что код с использованием асинхронности сложнее, чем выполнение построчно и мне кажется это очевидным.

А як в пхп можна зробити асинхронність, якщо там весь ап живе лише доки обробляється реквест, і кожен реквест це новий запуск апу?

Это ограничение наложено искусственно и служит скорее предохранителем от бесконтрольного роста порожденных процессов. Каких-то фундаментальных преград нет, но вот соотношение результат/трудозатраты выходит удручающим.

Не в цьому проблема складності реалізації фічі?

Если бы оно кому-то реально было надо уже давно все было бы.

Я видел очень много кода, в которых параллельное выполнение не сложнее последовательного. Это всё просто по тому что оно написано в стиле причинно-следственных связей, из разряда, чтобы посчитать A нам нужно посчитать B и C, для C нужно посчитать D, и так далее. Такое асинхронный код, особенно если он написан на Future/Promise/IO/Другая асинхронная библиотека, прозрачен (если честно, на всех продовских проекта всё что писал — оно в той или иной степени асинхронно). Если же варганить всякую писанину с сайд эффектами, кучей потоков хаотично меняющих стейт одного объекта, то ничего прозрачного там не получится и тут ваше утверждение верно. Загвоздка в том, что в таких случаях задача не разложена по полочкам а сделана на раз, два и в продакшн.

Мне в свое время пришлось вынужденнно уйти с Руби по причине наплыва «вайтишников» которые просто сбивали планку желаемой оплаты до уровня еды.Знаю что «зубров» не всегда берут, ибо ЗП уже не те и вакансий существенно меньше на Руби стало.Так что изучите какой нибудь другой новомодный язык, а нам старикам оставьте наш хлеб и не лезьте сюда

Как зубр вообще может быть в одной стопке с вайтишниками? Точно зубр?
С руби проблема только одна — вайти. Дальше все оки доки, если не слоупочить сильно.

А шо не так с руби в почти 2019? Почему новые проекты начинать не стоит?

При чем тут прошлое языка? Вы php7 видели? Руби, даже не знаю кто в 2018 на нем начинает новые проекты, он как язык неплох, но там явно меньше вакансий, особенно для новичков. На пхп же возьмут намного быстрее и он ничем не хуже это факт

Ясно, написали для написать, зачем писать о том в чем не разбираетесь?

Шановний типізація, там вже декілька років, — з 7 версії (привіт з 2015))). У 5 і 7 php немає повної зворотної сумісності. Судячи з усього Ви «великий» спеціаліст по php.

Це шкільний проект, що ви з пациками з паралельного класу запілили? Ну там, може і не проблема. Ми от командою, ентерпрайзний проект переводили якому 4+ роки — і проблем, там дуууууууже багато.
P.S. Типізацію, не вводять , а ввели 3 роки тому. І яке це має відношення до типізації? Динамічна типізація є типова не для скриптових мов, а для мов в яких сильна веб-розробка.

Хоч проект був і невеликий.
Не шкільний, але недостатньо великий.

може це Ви

не звіздіть

а то у Вас, щось не сходиться.
P.S.

Ентерпрайзний проект на пхп це сама по собі проблема. Таке чіпати не можна

якщо не писати тести і не рефакторити, то звичайно не можна, але то не залежить від мови, взагалі.

До чого там, типізація до рефакторинга і тестів? С — також слаботипізована і що, теж гавномова?)))

Не знаю щоб на С писали ентерпрайз проекти з тонами коду.

MICROSOFT
WINDOWS
3.11

UNIX-подібні OC і не тільки, він для того і розроблявся))) Ви мабуть не вкурсі, що «слабка» і «динамічна» типізація — то різні речі?)))

мы 12-ти летний переводили. Заменили mysql на mysqli , добавили пару try/catch и что-то пофиксили с mcrypt_.

а у вас что было? просто я сколько читал о проблемах — они возникают от кривого использования побочек.

Давно було (2016), всього не згадаю але те, що згадалось сходу (крім того, що Ви сказали):
— обробка помилок (set_exception_handler — костильно працював чи не працював взагалі);
— доступ до вложених методів\властивостей класів — не пам’ятаю, точно чому але виклик вкладених властивості не так, як очікувалось;
— навернулось багато розширень (привіт memcache);
— з інстансами класів, був прикол — якщо 5- версіях при створенні інстанса виникала помилка вертався null, а в 7 все зразу ламалось (це, до слова про «обернули в try/catch»);
всього не згадаю але нюансів хватало)))

Да, с ошибками и исключениями пришлось повозится. Тут я с вами согласен. Заняло процентов 80 всей миграции

Типизация это вот это: en.wikipedia.org/wiki/System_F. А то что в PHP это жалкая пародия на типизацию.

Угу, которая по-прежнему по умолчанию не включена. Эксперды по PHP пособирались тут я смотрю... Про use strict type забыли упомянуть...

Ах да...кстати, типизацию для свойств уже завезли?

Аж самому интересно стало). Пишут, будет в 7.4 — я думал, в 7.3 уже добавили, а нет.

ничем не хуже

RLY?!

Вы php7 видели?

Я видел. По сравнению с 5 версией конечно он получше будет, но советовать его в качестве первого языка...вы добрый однако. И дело не в пороге входа. Кроме как строгой типизации мне лично в ней ничего не понравилось.
Картинка к 10 винде, но чем дальше, тем больше она подходит и к PHP
i.kym-cdn.com/...​ginal/000/954/660/350.jpg

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

Я с ruby больше знаком, и сам Юкихиро Мацумото ставил цель создать язык с меньшими непредсказуемости, руби красивый, гибкий язык, но если так плохо с вакансия и лояльностью, лучше буду изучать php хоть, я его меньше знаю.

если хочется всю жизнь делать интернет магазины то с php не прогадаешь, зарплата весьма скромная, но работы много. Ruby был хипстерским языком и сейчас потихоньку умирает, осталась в основном поддержка уже сделанных проектов на нем. Советую все же C#/Kotlin/Java либо Javascript но это на любителя :)

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

13+ лет лячкаю код на пхп — ни одного магазина не делал ни разу.
ЧЯДНТ?

А вам не будет стыдно говорить что вы PHP девелопер? :-)

Ну так, немає гавно-мов — є гавно-кодери))) І повірте, там пофіг: шарпи, рубі, скала, 1с — вся справа в кваліфікації. Говнокодити можна кругом. Ми ж, всі знаємо — самі так писали)))

Розумієте, в чому проблема...

...немає гавно-мов — є гавно-кодери)))

Ну вроде умный человек, а такую ерунду пишете :))
php7+ проект, который соответствует psr, использует к примеру симфони компоненты с сильной командой — вообще ничем не уступает аналогичному проекту на той же джаве/c#, клепайте огромные «энтерпрайзы», без проблем. Ну и в связи с его динамической типизацией — имеет еще очень много своих преимуществ, которые облегчают и ускоряют разработку. Я на .net перепрыгнул когда — есть вещи которых мне не хватает. А так одно и тоже в принципе.
p.s. а php5 таки да, «гівномова»
p.s.2 если вы думаете что на java/c#/js разработчики сильнее — вы глубоко ошибаетесь :) По факту разницы вообще никакой, рулит архитектура проекта и использования всяких solid,kiss,dry принципов, хоть ddd внедряйте.
Поэтому я как перешедший на .net говорю — php7+ отличный язык, и на нем пишут очень много действительно сильный разработчиков серьезные хайлоад проекты с хорошей архитектурой. И получают не меньшие деньги, чем разработчики на других ЯП (вот в middle уровне, тут зп у php уступают джавистам).
Просто действительно сильные разработчики никогда не будут гнать на какой то язык, а вот от всяких недомидлов постоянно подобная вонь и исходит :) причем очень смешно слышать когда люди, не знающие какой то ЯП/технологию, критикуют его )

Навіщо брати сімфоні коли є повноцінна джава для ентерпрайзу мені зрозуміти не вдається.

А чем симфони/зенд не полноценен? Чего то не хватает?
А зачем брать джаву если есть полноценный .net core со своими плюхами?
Вы думаете на джаве быстрее/легче писать бизнес логику? Сложнее разбить приложение на слои? Какие преимущества?
Ответ один, php до 7 версии имел огромнейшее кол-во проблем. Сейчас он развивается полным ходом (к примеру wiki.php.net/rfc/typed_properties_v2). Еще и jit готовят.
Единственно — убила новость свежая про «распад команды» разрабов. Вот теперь нужно внимательно наблюдать — на чем порешают то..

то їм теж легше писати на сильно статично типізованій з всіма плюшками.

Расскажите это JS разработчикам :) хотя у них есть type script и прочее, но в php тоже типизацию подвезли, не забываем. Как по мне — то однобоко, на чем писать. Языки во многом похожи между собой, и да — у php отличается синтаксис — мне это тоже не сильно нравится. Но к этому моментально быстро привыкаешь.

Зе енд іс нір

ага, скоро ))

Скільки відсотків пхпшників її використовує?

Все 100% после решения тимлида... Разве бывает иначе?
Вообще если так размышлять — я сейчас копаюсь в г — в классе в котором намешан c#+html, 100500 foreach вложенных, дублирование кода адское. И что теперь — мне c# после этого обгадить? Если кто то не умеет / не хочет использовать современные возможности ЯП — это не значит что ЯП говно.

що спонукає НЕ ПИСАТИ типи

Вас походу не спасет никакой ЯП, вообще ничего, идите в грузчики лучше. Меня «спонукає» официальная документация, coding style в ЯП/команде да и вообще современные грамотные подходы к разработке. Что там у вас на эмоциональном уровне, хочется писать тип или нет — никого не волнует, вы должны это делать, если у вас такой стандарт.

Пхп беруть коли хочуть швидко щось розробити, в більшості випадків

Вот именно в этом пункте я и не согласен. Так же быстро набросать проект можно и на ноде и на питоне и на чем угодно. И опять же, в той же пыхе, взять симфони — уже не и не особо получится «хуяк хуяк быстренько и в прод».

Я просто живу в реальності, а не в конвенції рожевих стандартів.

Я тоже живу в реальности, в той где если я написал плохо — мой код просто забракуют на этапе коде ревью.

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

Расскажите мне, как сложно «наговнокодить» в джаве/.net/c++ ?)

Давайте я вам лучше расскажу как сложно наговнокодить в хаскеле/скале?

А по сабжу, вы рекомендуете автору начинать с хакселя? Мы сравниваем языка для старта.
кстати govnokod.ru/haskell
везде можно таки

Так в том и дело, если разраб не соображает — он будет писать ужасный код абсолютно везде, и никакая типизация вообще не спасет.

Так в том и дело, если разраб не соображает — он будет писать ужасный код абсолютно везде

При прочих равных говнокод на жабоскрипте и php доставит гораздо больше головной боли из-за худшей читаемости и более сложной отладки, чем на тех же шарпе или джаве. Поэтому разница есть... аргумент в стиле «всё равно мы все умрём».

никакая типизация вообще не спасет.

На практике получится, что на шарпе будет мало того, что кода гораздо меньше — его будет легче читать и отлаживать. Поэтому гипотетически да, вроде как не спасает, а если бы это коснулось Вас, то я бы посмотрел, кто что выберет — легаси на шарпе или легаси на жабоскрипте в схожих объёмах). Выбор, по-моему, очевиден.

Я бы вам сейчас скинул класс, с которым я работаю :)
там всё вперемешку, и c# и html и дикое дублирование кода (чтоб внести правку в результирующий html — надо в 10 местах эту правку добавить. И тут типизация вообще не причем. И язык тут не причем.

На практике получится, что на шарпе будет мало того, что кода гораздо меньше

это с чего вдруг?

Я работал и на C# и на JavaScript на последнем мешанина на очень большом проекте (не фронт энт вообще) таки отбила желание с ним связываться совсем. А на C# там хотя бы по типам и прочим можно хоть какую-то связь отстроить, на JS ну приходит тебе обьект и что дальше? Тебе ни IDE ни коллега не может обьяснить что это за обьект, откуда он и куда, особенно когда этим гребанными миксинами накромсали один обьект из нескольких других обьектов. Про замыкания и this молчу.

Я бы вам сейчас скинул класс, с которым я работаю :)
там всё вперемешку, и c# и html и дикое дублирование кода (чтоб внести правку в результирующий html — надо в 10 местах эту правку добавить.

«c# и html» — это какой такой «класс»? Я надеюсь, Вы сейчас не пытаетесь привести в пример Razor Pages (или Web Forms, или что там), когда мы сравниваем языки?

И тут типизация вообще не причем. И язык тут не причем.

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

это с чего вдруг?

С того, что в Шарпе уже 100 лет как есть куча фич, которые в JS только появились.

У меня языком старта является Scala. Не Scala as Better java а скала с теоркатом и полиморфным лямбда-исчислением (cats, shapeless, kind projectors), и ничо работаю же?

Никто не говорит что говнокодить нельзя, теоретическая возможность есть абсолютно в любом языке.

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

Даже используя фреймвоки RX и им подобные, вероятность ошибится( и наговнокодить) всё ещё высока, и это будет не обязательно заметно методом просматривания кода по диагонали.

Если мы говорим о функциональном подходе к многопоточности — фьючи к примеру, или же монада IO (ZIO или её аналог из котов, или же хаскельная изкоробочная). То чаще всего, код пишется описывая причинно следственные связи/преобразования которые необходимо выполнить, такой код гораздо проще читать и проверять, в нём же гораздо сложнее `нечайно` ошибиться — компилятор вам не даст. Не сойдутся типы. + В случае с монадой IO можно проверить правильность преобразований данных (проверили формулы прежде чем подставлять туда числа).

Если какой-нибуть неосилятор «этой вашей сложной функциональщины» будет туда пихать ручшные блокировки или другую подобную гадость — это видно за километр, глазами, для этого не нужно напрягать мозг.

Контрастируя с этим, «низкоуровневая» многопоточность с ручными блокировками потоков и ручным разграничением доступа к shared resource очень сильно подталкивает накосячить, ошибтся, схачить и т.д. И когда такое происходит нужно сильно напрячь мозг чтобы понять в чём же прекол.

Это всего лишь небольшой пример, подобных можно привести кучи.

То есть хаскель мы уже отбрасываем? или вы таки рекомендуете автору с него стартовать?

Не отбрасываем, если автор плотно тусуется с местной хаскель-тусовкой, или хотя бы имеет выходы на неё.

Так вы рекомендуете его как первый язык для старта, верно? Вы понимаете, что вы вообще как то субъективно даете рекомендации, основаны на вашем индивидуальном опыте. Я бы не особо рекомендовал стартовать с функционального языка, могут быть сложности. Я к тому что ваши советы из серии «я вот выучил это первым делом, вроде зашло — вам рекомендую», ну такое..

Я к тому что я пытался писать хороший код на куче языков от php и js до скалы и хаскеля, получилось только на скале. Если цель научиться строгать хоть шо нибуть — то конечно, джисы с питонами и вперёд грести.

т.е. то, что у Вас получилось только на скале, говорит о том, что и у других не получится?

Ну если эти другие — шортовы гении которые в школе в уме умели решать толстые примеры на упрощение в уме, щёлкали задачи по геометрии как орешки, запоминали стихи после 2-3 прочтений, то скорее всего, они будут писать хороший код. Но за своё время я таких людей обычно в гугле/фейсбуке/амазоне вижу. Иногда в закордонных конторах в виде основателей, а у нас почти не вижу.

То что нравится не?

мне самое главное получить профессиональную практику и умения

Так какая разница? Вакансии и по одному и по второму есть.

PHP, конечно. Тут и думать нечего.

А почему только эти два варианта? Есть много других языков с которых можно начать

Підписатись на коментарі