company_banner

Какой язык программирования учить, чтобы за вами охотились HR крупных компаний



    Десять лет назад язык программирования PHP был в лидерах рейтингов, а сейчас проекты в веб все чаще написаны на JavaScript и Python. Обидно потратить на изучение языка год или два, а потом остаться без работы.

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

    Зарплата


    Востребованность и перспективность языка можно оценить по зарплате, которую предлагают программистам. По данным «Хабр Карьеры», за второе полугодие 2019 года, самая высокая медианная зарплата у российских разработчиков, которые используют следующие языки.

    • 1 место — Elixir, 165 000 рублей.
    • 2 место — Objective-C, 150 000 рублей. Если посмотреть вакансии с этим языком, то от разработчика обычно требуется и знание Swift — преемника Objective-C.
    • 3 место — Scala и Golang, 150 000 рублей. Причем в 2018 году Scala был лидером рейтинга.

    Рост медианной зарплаты наблюдается у разработчиков на PHP, Python, C++, Swift, 1С и Ruby. Снижение зарплаты — у программистов на Kotlin (-4 %) и Delphi (-14 %).


    Разработчики на Delphi зарабатывают почти в два раза меньше остальных.

    На международном рынке ситуация другая. Судя по опросу, в котором приняли участие 90 000 пользователей StackOverflow, больше остальных зарабатывают программисты на Clojure, Scala, Go, Rust и R. Разработчикам на PHP, Assembly и VBA платят меньше, даже несмотря на больший опыт работы.


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

    Востребованность у работодателей


    Проанализировав вакансии, не получится выявить перспективные языки, но можно посмотреть, какие технологии нужны работодателям сейчас. И ситуация вряд ли изменится в ближайшие пару лет — ведь, даже если язык устарел, проекты нужно поддерживать или переписывать. Например, Objective-C все еще нужен несмотря на то, что его заменили Swift.

    По данным агентства DevSkiller, международным работодателям чаще требуются специалисты на JavaScript — этот язык упоминают в 40 % вакансий. Судя по тому, что на втором месте HTML/CSS, а на четвертом — SQL, спрос на frontend-разработчиков выше. Java упоминается в 31 % вакансий, .NET/C# — в 12 % объявлений.

    Как правило, компаниям нужны разработчики, владеющие сразу несколькими языками. Так, связка Java+SQL встречается в 26 % вакансий, .NET+JavaScript — в 8 %. В пяти из восьми сочетаний фигурирует JavaScript, который применяют как во front-end, так и в back-end.

    По данным небольшого исследования HH, на осень 2019 года работодатели чаще искали программистов на Java, PHP, 1C, SQL, Python, C#, JavaScript, C++. JS немного отстает, так как его фреймворки: Vue, React, Ember, JQuery, Angular, учитывались отдельно. Если смотреть общую статистику, то в России этот язык также популярен.

    Интерес сообщества


    Когда разработчик сталкивается с чем-то непонятным, он гуглит вопрос. Сервис TIOBE анализирует количество запросов и составляет рейтинги популярности языков программирования.

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

    В феврале 2020 года чаще всего программисты искали информацию по Java, C и Python. За год возрос интерес к С и С# — на 4,3 % и 3,08 % соответственно. Из списка 20 популярных языков, по всей видимости, выйдет Objective-C. Сервис предполагает, что падение на семь позиций за месяц произошло из-за «устаревания языка и укрепления позиций Swift, который его заменяет».

    Учитывая усредненные годовые данные, TIOBE показывает изменения за последние пять лет. Стремительный рост у Python — он переместился с седьмого на третье место. В лидерах — классические Java и C, C++, C#.

    Язык программирования 2020 2015 2010
    Java 1 2 1
    C 2 1 2
    Python 3 7 6
    C++ 4 4 4
    C# 5 5 5
    Visual Basic .NET 6 10 -
    JavaScript 7 8 8
    PHP 8 6 3
    SQL 9 - -
    Objective-C 10 3 21
    Lisp 31 18 16
    Ada 35 29 24
    Pascal 229 16 13

    Мнение сообщества


    Портал для IT-специалистов Stack Overflow спросил 90 000 разработчиков о популярных языках программирования. Опрос показывает мнения международного сообщества — код на самых популярных языках вы встретите в проектах чаще остальных.

    Чаще всего разработчики используют JavaScript — это язык лидер уже несколько лет. Если же сравнить рейтинги 2018 и 2019 годов, то рост популярности демонстрирует Python.

    2019 2018
    JavaScript JavaScript
    Python Java
    Java Bash/Shell
    Bash/Shell/PowerShell Python

    В рейтинге 2019 года (мнения за 2018 год) самыми любимыми разработчики назвали Rust, Python и TypeScript. Годом ранее в списке были Rust, Kotlin и Python.

    Интерес у сообщества вызвали Python, JavaScript и Go, их хотят изучить 25,7 %, 17,8 % и 15 % разработчиков соответственно. В рейтинге языков, с которыми разработчики не хотят связываться, первые три места заняли VBA, Objective-C и Assembly.

    Популярность кода


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

    На первом месте уже несколько лет находится JavaScript. В исследовании за 2019 год второе место занял Python, подвинув на строчку ниже Java, рост показывают C# и Shell.


    Графики показывают популярность отдельных языков. Видно, что в последние годы Ruby используют реже.

    Как выбрать перспективный язык для изучения


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

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

    Так, менеджеры Google из-за трений с Oracle по поводу использования Java сделали свой выбор в пользу Kotlin. И включили его в состав Android Studio 3.0 — официального инструмента для разработки операционной системы Android.

    Дмитрий Рогов, заместитель гендиректора по технологическому развитию «АйДи — технологии управления»

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

    Вместо Objective-C для программирования на iOS стоит смотреть на Swift. К этой же категории можно добавить Erlang. Также сейчас много разнообразных JVM-языков, например: JRuby, Jython и JLog, на которые я бы не стал тратить время.

    Дмитрий Вдовин, старший программист группы разработки карты рассрочки «Совесть»

    Директор департамента разработки ПО компании «Рексофт» Николай Сокорнов в начале пути советует не гнаться за модными языками вроде Go или Rust, а сосредоточиться на проверенном временем языке: для back-end изучать Java, для front-end — JavaScript.

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

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

    Язык определяет мышление. Выбрав на старте JavaScript, вы затрудняете себе понимание back-end. Разрабатывая на C++, вы не ощущаете легкости параллельной обработки сотни HTTP REST запросов. Выбрав одну тему и освоившись с ней, посмотрите на другие технологии.

    Анна Мелехова, архитектор платформы Acronis

    Как выбрать язык программирования


    1. Узнайте, какую зарплату предлагают разработчикам на различных языках.
    2. Посмотрите, насколько востребован язык у работодателей: специалистам по редким языкам могут платить больше, но и работу найти сложнее.
    3. Отсейте устаревшие языки, которым уже нашли замену.
    4. Посмотрите, насколько большое сообщество у выбранного языка. В перспективе вам будет проще найти ответы на сложные вопросы.
    5. Изучайте то, что интересно, и не ограничивайтесь одним языком.

    Статья подготовлена Mail.ru Cloud Solutions

    Mail.ru Group
    Строим Интернет

    Похожие публикации

    Комментарии 81

    • НЛО прилетело и опубликовало эту надпись здесь
        +1
        Хм… а расскажите, чем плох Go? Было с ним небольшое знакомство, показался очень интересным.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Отсутствие дженериков, поразительная многословность, отсутствие перегрузки функций, плохой подход к обработке ошибок, отсутствие явно напрашивающихся библиотек(например для работы с потоками), «токсичность» некоторых членов сообщества, крайне странная работа с модулями и версиями, необходимость в GOROOT и GOPATH…
            Это все, конечно, мое субъективное мнение.
              0
              отсутствие явно напрашивающихся библиотек(например для работы с потоками)

              Эм… В гоу есть goroutines, каналы и пакет sync. Что еще нужно?


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

              В чем странность? Мое мнение, что, конечно, системе зависимостей далеко до, например, того, что мы имеем в PHP (composer), но что же в go mod странного?


              На счет GOPATH — это не совсем так. Причём давненько ;)

                0
                поразительная многословность

                По сравнению с Java, например?

                отсутствие явно напрашивающихся библиотек(например для работы с потоками)

                Вы действительно знакомы с Go?

                Зачем там библиотеки если это ядро самого языка.

                необходимость в GOROOT и GOPATH…

                Вы действительно знакомы с Go?

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

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

                И это не еще считая альтернативного способа go mod (который уже пару версий как основной)

                плохой подход к обработке ошибок

                Или напротив — хороший.

                tendium
                Отлично, но в реальном мире (если мы не пишем библиотеку для общего назначения) одного слова часто недостаточно. Да и емкое слово еще надо придумать. Ну, либо, придется лепить слова в одно, без подчеркиваний и кемелкейса


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

                0
                бизнеслогику на Go писать немного неудобно.
                а так — замечательный язык(хотя и со странностями)
                  +3

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


                  Вот примеры того, что мне не нравится:


                  • пакеты в go определяются именем каталога, причем документация говорит о том, что

                  Good package names are short and clear. They are lower case, with no under_scores or mixedCaps. They are often simple nouns [...]

                  Отлично, но в реальном мире (если мы не пишем библиотеку для общего назначения) одного слова часто недостаточно. Да и емкое слово еще надо придумать. Ну, либо, придется лепить слова в одно, без подчеркиваний и кемелкейса. С учетом того, что всё приложение состоит из пакетов (особенно, если оно хоть как-то более-менее сложное), это превращается в проблему для описания бизнес-логики в go (каждый раз, когда мне это нужно сделать, я убиваю в себе перфекциониста). Вот пример названия пакета из реальной жизни: validatingwebhookconfiguration (kubernetes, если что).


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


                  • более того, разработчик часто вынужден лезть в инстанс глобального логгера, потому что иногда нужно выводить логи из сторонних библиотек. Понятное дело, что адекватные программисты делают это в самом начале инициализации приложения и больше этого не делают, но выстрелить себе в ногу очень легко. В мире здорового человека для логов в библиотеку можно было бы передать имплементацию некоего интерфейса, но в мире курильщика так почти никто не делает. Вообще, в целом в go — в моем восприятии — почему-то крайне редко используется методология dependency injection.


                  • система structure tags, имхо, достаточно крива в плане синтаксиса. В частности меня добивает тот факт, что разбить длинный тег структуры на несколько строк просто нельзя. Если структура имеет достаточно сложное описание тэгов, то без вариантов — у вас будет длинный рояль в кустах.


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


                  • для новичка, наверное, будет удивлением, но в функцию, описанную как func name([]interface{}) нельзя передать переменную типа []string, например (вместо string любой конкретный тип). На это, понятное дело, есть свои причины, но тем не менее, это порой вынуждает писать полотна boilerplate кода.


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


                  • стандартов по неймингу методов, имхо, тоже недостаточно наработано. Например, если у вас есть геттер, который возвращает, скажем entity, то часто у вас метод будет назван как Entity() (без Get). Но если у вас есть экспортируемое поле с этим же именем, то вы уже не можете использовать геттер без Get.


                  • вообще, с геттерами/сеттерами всё не однозначно — у меня сложилось впечатление, что авторы по возможности дают напрямую работать с полями объекта. Но тут есть проблема — возможно, вы хотите дать прочитать, но от изменения объект не защищен. И тут уже как бы ответственность лежит на программисте. И ладно, если вы используете стороннюю библиотеку — всегда можно сказать "используй строго в соответствии с документацией", но если у вас есть свой внутренний проект, то рано или поздно кто-то создаст неявные зависимости там, где вы их не ожидали увидеть.


                  • использование импорта пакета для получения сайд-эффекта а-ля import _ "somepkg" за счет вызова функции "init" можно, имхо, смело считать bad practice, но в мире go это достаточно распространенная практика.


                  • если вам надо разобрать в go json с заранее неизвестной структурой (или же с динамической структурой), то вы обречены на кучу бойлерплейта и врапперов. При этом встроенная библиотека для декодирования json эффективностью работы не впечатляет.


                –3
                К сожалению «орогие» языки не для удалённого фриланса, возможно нынешний массовый переход фирм на удалёнку несколько изменит ситуацию, но особой надежды на это нет. Поэтому так и сидим на пхп/яваскрипт, хотя уже лет 10 как скучно это до безобразия, при том что начинали с асма и си которые очень нравились.
                  +3
                  Несмотря на все разговоры об умирании PHP (в 2012-ом), все же решил изучать его. Немного, конечно, не удобно что его хоронят. Но, с другой стороны, пришло понимание того, как вообще устроенно программирование, а благодаря тому, что язык развивается стали понятны некоторые аспекты из других языков. И последние года три есть четкое понимание что я зык — это инструмент и когда возникнет необходимость смогу заменить инструмент. Доказательством тому пет-projects на go и готовлюсь предложить правки для фреймворка Phalcon (понравилась zephyr`ка).
                    +9

                    PHP хоронят уже лет 20 — столько сколько меня зовут начинать на нём новые проекты.

                      +1
                      Солидарен с вами.
                      Многие не задумываются о том, что не бывает серебряной пули. И для каждого (мне так, кажется) языка есть своя область применяя. Просто надо знать и понимать, что для чего. А так-то да, микроскопом гвоздь тоже можно забить.

                      Платят не за язык, а за то, как его используешь.
                      +4
                      Несмотря на все разговоры об умирании PHP (в 2012-ом)


                      Ну PHP создан был для того, чтобы умирать)
                      +2

                      Вопрос на засыпку: сколько потеряешь в зарплате, переключившись с PHP на Java, если на PHP уже практически достиг потолка зарплат и уже получаешь больше чем половина Java разработчиков с опытом 10+ лет?

                        +1
                        У Вас, имхо, какая-то очень атипичная ситуация.
                        По нормальному кодер джун на яве без реалього опыта получает больше чем топ кодер на пхп с 20+ годами опыта.
                        Да, до джуна на яве расти дольше чем до миддла на пхп, но тем не менее.
                          +2

                          До Джуна расти? С чего это? Джава это же не Аси или брейнфак, там ничего сверхсложного нет.

                            +2
                            Зависит от определения джуна.
                            Последнее время слышим определение джуна как «я прочитал туториал по языку, порешал задачки, если вдруг затруднюсь — посмотрю функции в мануале или погуглю.». Формированию подобного мнения способствует дикое количество курсов «ява за 30 часов».

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

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

                            Ни в коем случае не настаиваем на своей правоте — мы просто объясняем о каких джунах мы говорили.
                              0

                              Джунство у вас зависит от языка? Если человек, полжизни писал на JS или Java, потом прошёёл курсы TypeScript/Kotlin за 30 часов — он джун в последних?

                                +1
                                Джунство у вас зависит от языка?
                                Время до джунства. Если пхп на порядок проще явы, то представляется самоочевидным, что джуном на нем можно стать быстрее.

                                Если человек, полжизни писал на JS или Java, потом прошёёл курсы TypeScript/Kotlin за 30 часов — он джун в последних?
                                Затрудняемся ответить.
                                Учитывая условно-совместимый бакграунд — расти до сеньера он будет на порядок быстрее человека только пришедшего в профессию.

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

                                Он однозначно не миддл, если вопрос в этом. Т.к. кроме базы в котлине\тайпскрипте за 30 часов ничеге не изучить. Однако с учетом бакграунда по сути в этой же области — за год вполне может стать сеньером, что для новичка в котлине просто фантастика.
                                0
                                так что бы все базовые функции знать не лазя в мануал, знает на том же уровне все нужные либы и иде и системы версий

                                Что есть базовые функции и либы?) Я до сих пор зачастую лезу по синтаксису в гугл, если конструкциями/функциями пользуюсь не часто.

                                На мой взгляд джунство это не просто знание технологии, а знание+уровень умения учиться и разбираться.
                                  0
                                  Что есть базовые функции и либы?)
                                  В случае с php это всё отсюда www.php.net/manual/en
                                  Базовые знания — значит что необязательно знать все флаги или запоминать порядок аргументов, но о наличии функций с нужным функционалом и их поведении знать надо.
                                  Что бы не было шедевров вида sleep(0.5), тогда как sleep принимает аргументом только целые секунды (в одном из тестовых заданий было у кандидата) или что бы не велосипедить перевод 2011-09-13 в unixtime (опять же в одном из тестовых заданий и кандидат гордился этим).

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

                                    Хороший пример, да. Противоречащий сам себе. sleep(0.5) — типичный пример, как люди уповают на своё знание. Если не пользуешься чем-то, что такие ляпы не даст совершать (нормальная IDE, отдельный статанализатор и т. п.), то гуглить (поиск гугла по php.net лучше поиска самого сайта) сигнатуры "базовых функций и либ" обязательно, чуть ли не при каждом использовании.


                                    Я бы вообще к базовым PHP относил только основную работу со строками и массивами, ну и базовую с датами. Я вот за 20+ лет разработки на PHP не знаю даже полного списка поддерживаемых из коробоки баз данных. А когда открываю его, как сейчас, то о трети баз данных и не слышал никогда. Вы реально считаете, что джуну нужно знать, что PHP поддерживает DB++?

                                      0
                                      Хороший пример, да. Противоречащий сам себе. sleep(0.5) — типичный пример, как люди уповают на своё знание. Если не пользуешься чем-то, что такие ляпы не даст совершать (нормальная IDE то гуглить (
                                      Не противоречащий, т.к. мы сказали «надо знать», а не «уповать на знание»:) Вы же не гуглите оператор инкримента что бы не ошибиться «уповая на знание»?

                                      Вы реально считаете, что джуну нужно знать, что PHP поддерживает DB++?
                                      Ща словим минусцов:)
                                      Сам факт что поддерживает? Да, иначе это «английский со словарем», все равно как в английском не знать о существовании Future Perfect Continuous скажем или не знать как включается 6 передача на авто, т.к. «все равно первые два года выше 70км/ч нельзя ездить».
                                      Учитывая что расширение экспериментальное — можно не знать деталей функций, но хотя бы что в принципе функции могут делать — знать надо. Что бы просто читая чужой код и внезапно встретив dbplus_find не думать «что это вообще за на фиг».

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

                                      Если подходить к знанию языка по другому, то что дальше? Не надо знать sleep, потому что есть более универсальный time_nanosleep? Не надо знать родные функции mysqli потому что есть более универсальный pdo? Не надо знать зачем нужно экранирование кавычек потому что во всех нормальных фреймворках оно сделано на автомате? Можно забить на знание функций работы хмл, т.к. они редко встречаются в проектах и всегда можно нагуглить?
                                        0
                                        Ответ на ваш последний абзац почти везде — «да». Для любого ЯП. Сильные разработчики, по моему опыту, выделялись совсем другими характеристиками.
                                        Ответ — так пхп же не поддерживает мемкэшед
                                        Берешь и гуглишь «PHP Memcache», очень легко.
                                          +1
                                          Ответ на ваш последний абзац почти везде — «да». Для любого ЯП. Сильные разработчики, по моему опыту, выделялись совсем другими характеристиками.
                                          Для сильных разработчиков это всегда было обязательной базой.
                                          Какой это разработчик на php если он php не знает? Чё за бред вообще?

                                          Берешь и гуглишь «PHP Memcache», очень легко.
                                          С такой логикой можно взять школьника с 9 классами образования. Он тоже может нагуглить «php memcache», равно как и ООП подучить.
                                          По Вашему в вакансиях пишут требования — знания php, знание yii, знание zend с целью узнать может ли разработчик нагуглить информацию по ним? Или с целью нанять разработчика знающего их?
                                          Вы когда отдаете документы, допустим, на перевод, Вы ожидаете кого там увидеть в работниках? Человека знающего «английский со словарем»?
                                            0
                                            Какой это разработчик на php если он php не знает? Чё за бред вообще?
                                            PHP знает, библиотечные функции не все знает (=не может о конкретных поговорить, хотя в прошлом мог работать и с mysqli, и с XML, а мог и не работать). Поговорить о знании ЯП можно спросив про работу со ссылками, о сборке мусора, о типах, о классах. Дать несложное задание на кодинг и посмотреть результат (а гугл в помощь). Знание ЯП — само по себе лишь маленькая часть профессиональных навыков разработчика, так что странно на этом заостряться. Мы спрашивали больше о принципах дизайна, архитектуры кода и проекта, о их реальных проектах (это даже важнее остального). Кстати, у разработчиков с опытом преимущественно в других ЯП тоже был хороший шанс.
                                            знание yii, знание zend
                                            По моим впечатлениям конкретно на фреймворках на собеседованиях никто не заостряется. Желательно только иметь опыт хоть с каким-то в данной области.
                                            Вы когда отдаете документы, допустим, на перевод, Вы ожидаете кого там увидеть в работниках? Человека знающего «английский со словарем»?
                                            Я в основном ожидаю увидеть перевод. Сильный лингвист может и только со словарём, да. Дальше аналогия ломается, т.к. перевод сильно отличается от разработки.
                                              0
                                              знание ЯП — само по себе лишь маленькая часть профессиональных навыков разработчика, так что странно на этом заостряться
                                              Это обязательная часть навыков. Это как колеса у автомобиля. Часть маленькая, но если хотя бы одного нет — далеко не уедешь.

                                              PHP знает, библиотечные функции не все знает
                                              Тогда он не знает php. В чем его знание состоит? В том что он знает что после функций надо точку с запятой ставить? Офигеть нормы знания.

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

                                              Вот здесь habr.com/en/news/t/495968/#comment_21470146 abar и F0iL неплохо написали на эту тему.
                                              Вот главное оттуда
                                              Люди просто путают «освоить синтаксис языка» и «освоить язык».

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

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

                                              Я в основном ожидаю увидеть перевод.
                                              Перевод и гугл транслейт может сделать.
                                                +2
                                                Хорошо. Мне остаётся смириться, что я не пройду у вас собеседование, но это навряд ли повлияет на мою жизнь — по моему опыту такие, как у вас мерки достаточно редки. Принимать ваши мерки к себе на собеседование я не буду потому, что по моему опыту собеседований и долгосрочным итогам самые полезные разработчики выявляются иначе.
                                                  +1
                                                  Вы себя позиционируете как сеньер (выше Вы говорили про зарплату 4к баксов в месяц и то ли 10 то ли 20 лет опыта), говорите о самых полезных разработчиках (не упоминая даже языка программирования как такового) — которые опять же сеньеры.
                                                  Но речь-то черт побери шла о джунах.
                                                  Директор-сеньер таксопарка может и прав не иметь, но когда прав не имеет водитель-джун это уже трэш.
                                                  +2
                                                  PHP знает, библиотечные функции не все знает
                                                  Тогда он не знает php. В чем его знание состоит

                                                  Не стоит судить так категорично. Невозможно знать всю стандартную библиотеку языка, т.к. языки развиваются, если только они не мертвые. Также невозможно знать все особенности всех библиотек и фреймворков для этого языка. Везде нужна своя мера, в этом суть.
                                                  В конечном счете значение имеет то, как, имея какое-то знание средств языка, ты сможешь решить ту или иную задачу и как сделаешь это эффективно… или условно эффективно, лишь бы заказчик был доволен.
                                                    0
                                                    Невозможно знать всю стандартную библиотеку языка
                                                    Вы, вероятно, пропустили часть дискуссии выше. Речь не шла о знании вплоть до всех флагов, и даже порядок аргументов можно не везде помнить.
                                                    А вот знать какие функции есть в языке и какое их назначение — особой проблемы нет и это база знания языка, как таблица умножения.

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

                                                    лишь бы заказчик был доволен.
                                                    Заказчик бывает доволен сайтом который грузится 10 секунд и имеет целый набор уязвимостей. Так себе критерий.
                                                      +2
                                                      Речь не шла о знании вплоть до всех флагов

                                                      А вот знать какие функции есть в языке и какое их назначение — особой проблемы нет

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

                                                      Заказчик бывает доволен сайтом который грузится 10 секунд и имеет целый набор уязвимостей.

                                                      Все должно быть регламентировано, иначе можно бесконечно долго доводить до «идеала».
                                                      Допустим, время отклика приложения было 10сек, вас это не устроило, вы оптимизировали работу и добились отклика в 1сек… а почему не 0,1сек… почему не 0,01сек? Где грань?
                                                        +1
                                                        Прочитайте, пожалуйста, дискуссию выше. На все эти вопросы ответы были уже выше, мы сейчас начинаем по второму кругу повторяться — поэтому ответим упрощенно.

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

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

                                                        Все должно быть регламентировано, иначе можно бесконечно долго доводить до «идеала».
                                                        Количество функций в ЯП не бесконечное.

                                                        Допустим, время отклика приложения было 10сек, вас это не устроило, вы оптимизировали работу и добились отклика в 1сек… а почему не 0,1сек… почему не 0,01сек? Где грань?
                                                        А это опять критерий вида «заказчик доволен», к знанию языка он неприменим.
                                                        Грань очень простая: не должно быть недостатков/ошибок и/или избыточных затрат времени произошедших из-за незнания штатных функций ЯП.

                                                        Это не значит что надо брать д-еба который не знает программирования.
                                                        Суть в том, что если Вы нанимаете а) программиста б) на ЯП… то он должен уметь а) программировать б) знать ЯП.
                                                          +1
                                                          Я прекрасно понимаю вашу позицию. Я был столь же категоричен раньше. Сейчас же я более сдержан в своих требованиях и ожиданиях.
                                                          Количество функций в ЯП не бесконечное.

                                                          Оно конечно, как и все в реальном мире. Но оно (количество) изменчиво.
                                                          Я привел вам простой пример о функциях массивов и строк в php. Их более двух сотен. Нужно ли помнить их все? Используются ли они все в реальной жизни? Помните ли и используете ли вы их сами?
                                                          Принцип Парето никто не отменял: в разработке в 80% случаев используется 20% функционала ЯП / фреймворка.

                                                          Это не значит что надо брать д-еба который не знает программирования.

                                                          Не надо в крайности бросаться. Я лишь акцентирую внимание на необходимой достаточности знаний.
                                                            0
                                                            Суть в том, что если Вы нанимаете а) программиста б) на ЯП… то он должен уметь а) программировать б) знать ЯП.

                                                            Не согласен с "б". Должен он знать ЯП на достаточном для вас как для работодателя уровне. Собственно и программирование так же.

                                  0
                                  Все так и было, но лет 20- тому назад). Сейчас на PHP много разного e-commerce с деньгами и уже не так много специалистов. Java разработчиков наоборот штампуют конвейерами, да и область использования весьма разношерстна — от автоматизаторов тестирования до различных крутых энтерпрайзов.
                                    +2
                                    Сейчас на PHP уже не так много специалистов.

                                    В картинке к статье зарплата пхп спецов 100к — вторая снизу — ниже только дельфи.
                                    При этом по количеству спецов пхп опять же на втором месте, только уже сверху, на первом яваскрипт.
                                    Таким образом имеем — большая конкуренция за небольшую зарплату, каким образом это «не так много спецов на пхп».
                                      0
                                      Картинка медианная. Это значит, что она призвана отражать зарплаты основной массы. На самом деле было бы интересно увидеть расклад по опыту/тайтлам, но возможно это не входит в цели поста. Могу лишь предположить, что речь идет о разработчиках уровня junior и middle.
                                        0

                                        100к больше похожа на медианную по всем уровням. И, наверное, в реальности миддловая плюс-минус.

                                    +1
                                    Когда я переходил с позиции senior fullstack PHP на middle fullstack Java, моя зарплата упала на ~20%. В мире PHP есть востребованность в хороших специалистах и компании готовы (были) платить много, я получал далеко не «потолок».

                                    Сам переход был обусловлен мыслями о будущем. В пхп я провел около 10-ти лет. Ушел когда мне было 36. В целом хотел тихой гавани в большой компании, где цикл разработки большой, а ты один из множества старперов. Мои ожидания полностью оправдались — большая компания, куча «возрастных» специалистов, где я со своими почти 40-ка выгляжу достаточно молодо. :)

                                    А сами задачи интересней и сложней тех, с чем приходилось сталкиваться в PHP мире. Не берусь утверждать что так везде.
                                      0

                                      А меняли область разработки? Стали писать под mobile или desktop или, грубо говоря, "лишь" сменили PHP на Java, Symfony на Spring, Doctrine на Hibernate, а так продолжали решать те же бизнес-задачи, что и раньше?

                                        0
                                        Сменил Laravel на Spring, бизнес задачи остались теми же с поправкой на размер компании.

                                        Переход на самом деле занял время и усилий. На первых порах было сложно отказаться от многих PHP-привычек — сложно жилось без «магических» методов, очень много сервисов, dto, репозиториев (куда больше чем в PHP), в работе с базой пришлось значительно чаще использовать разные возможности БД. Преодалеть привычки помогло общение с коллегами и code review.
                                          0

                                          Звучит так, что мне перейти будет проще. :)

                                            0
                                            сложно жилось без «магических» методов, очень много сервисов, dto, репозиториев
                                            Звучит как переход от более ситуативной разработки (aka г-код) к более систематической. Вред implicit кода и разделение ответственности описан еще в книжках 90-х (это самые старые, попадавшиеся мне). От ЯП вообще не зависит.
                                        +1

                                        Может она атипичная для России, но вот Киеве смотрю аналогичную статистику (медианы, доллары в месяц, чистыми):
                                        Junior Java — 900
                                        Junior PHP — 900
                                        Senor Java (10+ лет опыта) — 4400
                                        Senior PHP (10+ лет опыта) — 4000

                                          +2
                                          Senior PHP реально мало, ибо проектов, где можно реально дорасти до senior уровня на php — гораздо меньше, чем для Java мира. Отсюда более жесткая конкуренция за спецов и более высокие зп.

                                          В РФ Java получают больше за счет того, что компании типа Сбера и прочие, могли заливать баблом спецов. А PHP больше про компании, которые считают деньги.
                                            +1
                                            Любопытно, можно пример вакансии сеньера пхп с такой зарплатой? С трудом представляем себе требования.

                                            В питере скорее так (по знакомым, не по статистике)
                                            Junior Java — 1500
                                            Junior PHP — 600
                                            Senor Java (10+ лет опыта) — 8000
                                            Senior PHP (10+ лет опыта) — 2500
                                            По москве на 20-50% больше, но пропорция сохраняется.
                                            Но — java только в крупных компаниях, где только оффлайн, офис, диплом, NDA и все корпоративные вещи.
                                              0

                                              Не прямо 5, но 4,5+ тут, например


                                              А 5 не просто рассматривают, а иногда кажется, что продешевил :)


                                              По Java с теми же пераметрами предложений раз в 6 больше, а если зп/ожидания уменьшать, то сближаются числа, что косвенно подтверждает статистику.

                                        +9
                                        Зарплаты выше среднего по какому-то языку — это всего лишь видимый результат перекоса спроса и предложения. Оно плохо коррелирует с заявленной темой статьи, так как может быть результатом множества разных ситуаций. Например — технология умирает, а легаси очень много. Зарплаты высокие, потому что количество желающих сокращается сильно быстрее объемов легаси (обычно из-за фундаментальных проблем именно самой технологии или появления лучших альтернатив). Но тренд технологии исключительно нисходящий, и желающих влиться в это дело в далеком будущем как максимум ждет непыльное местечко а-ля COBOL и государственный софт в США. Но таких мест будет очень мало, и всех, кто не смог на них попасть, ждет гораздо более прозаичный вариант: увольнение и отсутствие другой профильной работы.

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

                                        Смотреть только на зарплаты — занятие сомнительное.
                                          +2
                                          Оно плохо коррелирует с заявленной темой статьи

                                          Если верить графикам в статье, то при медианной зряплате менее 8$/час как в РФ, и среднемировых около 30$ за вами будут охотиться HR любых компаний, какой бы язык вы не выбрали. При таком прайсе даже индусам сложно конкурировать.
                                            +1
                                            технология умирает, а легаси очень много. Зарплаты высокие, потому что количество желающих сокращается сильно быстрее объемов легаси
                                            С Delphi почему-то в этом случае выходит ровно противоположный эффект по зарплатам. Или там обратная ситуация: объемы легаси быстро сократились (но как такое могло произойти?), а количество желающих или способных переучиться не так уж и велико?
                                              +1
                                              объемы легаси быстро сократились (но как такое могло произойти?)

                                              Варианты из личного опыта:


                                              • фирмы, использующие заказной софт на Delphi, загнулись
                                              • фирмы, использующие заказной софт на Delphi, перешли в веб. Сам несколько раз инициировал и принимал участие в подобных проектах в 2000-х, основной аргумент был: "у вас всё пиратское, а за это начинают сажать. или платите за windows, firebase (или как там его), сам delphi, или переписывайте на FOSS, желательно веб. Я, кстати, могу недорого переписать на LAMP"
                                              • фирмы, использующие заказной софт на Delphi, перешли на заказной .Net (на Java ни разу не видел)
                                              • фирмы, использующие заказной софт на Delphi, перешли на коробочный софт или SaaS
                                                0
                                                Учитывая, что на Delphi делалось очень много наколенной частной автоматизации (или в пределах одного рабочего места, или чуть распределенно, но всё равно очень частно) — логично предположить, что это как раз тот вариант, при котором выкинуть имеющееся и заменить его более общим решением (1C и подобным) наиболее просто.

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

                                                  Ну да, "заказной" в моём комменте часто означало по факту "сын НОК на программиста учится же? Пускай нам склад сделает, а мы даже заплатим ему две стипендии его. Всё равно каждый день играть приходит"


                                                  Аргумент про пиратское стал весовым, когда реально начали за пиратство привлекать, до этого, как говорится, строгость законов компенсировались их неприменением. УК РФ вроде в 96-м приняли новый, да и до этого уже какие-то статьи были, а кампанию врде как раз в 2000-м и начали.

                                                    0

                                                    Ну вот про базу не нужно, мало кто использовал interbase от Борланд я видел в основном firebird (который полностью открытый и бесплатный продукт) а вот среда разработки да мало кто платил за лицензию, не говоря уже о компонентах. Тут скорее сыграл фактор резкого разового увеличения затрат, и многие пошли по пути раз уж всё равно платить то переделаем на более модном (при этом от вэб автоматизации многие страдали, т.к. более менее удобный для повседневных задач интерфейс стало возможно делать не так давно, а те кто умеет в них появились ещё позже) но да где работа заключалась в нажатии 2х кнопок и 3х полей ввода там веб был отличным вариантом.

                                                    0
                                                    К слову 'перейти на веб' можно уже вполне в пределах Delphi. Несколько отличных фреймворков в помощь: UniGUI, TMS Web Core.
                                                      0

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

                                                        0
                                                        Так и вебовый нормальный разработчик платный и недешевый (по своему опыту). Делфи разработчики стоят чуть дороже вебовых, зато производительность разработки на Унигуе выше просто на голову по сравнению с 'традиционным' вебом, как вот у нас было: jQuery фронт + Delhi бэк. Опять же по опыту.
                                                    0
                                                    Утверждают, что зарплаты в паскале выше, чем в C#, JS и Python
                                                    www.businessinsider.com/the-top-coding-languages-with-the-highest-salary-2020-4#pascal-is-associated-with-an-average-global-salary-of-6277390-9
                                                  0
                                                  Есть, по крайней мере, один язык, который занимает одно из первых мест, если не первое, по реализации его на разных языках программирования. :) (Forth, Форт)

                                                  Например это легко проверяется по выборке его упоминания в проектах на Github

                                                  P.S. Стоит ли он изучения каждый может решить сам, но понимание принципов его экосистемы может оказаться полезным для расширения кругозора возможностей инструментальных средств применяемых с этим языком.
                                                  И, да, Вы не найдёте вакансий по нему в кадровых агенствах и заинтересованности Теам лидеров в нём :)
                                                    +3
                                                    Если действительно хотите, чтобы за вами высунув язык гонялись все хедхантеры планеты, учите COBOL. Крепко учите.
                                                      0
                                                      После нынешней пандемии буквально будут рвать на куски. ЕВПОЧЯ
                                                      0

                                                      Забыли vhdl и verilog

                                                        +1

                                                        Можно ли называть языки аппаратного описания языками программирования? На мой взгляд, их стоит отделить.

                                                          0
                                                          Ну за них тоже деньги платят. При чём не плохие
                                                            +1

                                                            По тем вакансиям, что видел я, у меня сложилось впечатление, что на том же Java, например, стартовать проще. Зарплаты тех, кто пишет под ПЛИС, выглядят в большинстве ниже. Правда, смотрел я предложения российского рынка труда. Может, в международной выборке ситуация иная. Также мне показалось, что в случае IP под специализированные микросхемы (ASIC), ситуация лучше. Правда и хлопот там побольше, чем в случае с ПЛИС.

                                                        +3
                                                        На PHP на Zend/Symfony очень хорошие зп. Скажем в Москве до кризиса найти на 140к мидлу было достаточно просто (ну тут естественно, идет symfony + mysql/postgres + redis/elastic + rabbit/кафка + шардирование итд). Т.е. фактически обычный энтерпрайз стек просто на ПХП.

                                                        Плюс очень хорошие зп были у тех, кто для амеров под заказ делал сайты на Wordpress/Magento.

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

                                                        Ну и фразу: «Хочешь деньги, учи Java» — никто еще не отменял.
                                                          +1
                                                          Если ты эксперт в каком-то ЯП, то условие популярности не столь важно, так как ты и так будешь востребованным.
                                                            +1
                                                            Perl. :'(
                                                              –1
                                                              мне python нравится, очень удобный, а другие языки изучать лень
                                                                +2

                                                                Синдром утенка?

                                                                0

                                                                Очень хорошая статья, лично я учу питон из за его плюшек и очень лёгкого синтаксиса

                                                                  +2

                                                                  Динамическая типизация вас не смущает?

                                                                  +2

                                                                  Даже не стал читать. Заголовок неправильный. Чтобы за вами охотились HR любой компании надо мозги иметь а не язык знать.

                                                                    0

                                                                    Чтобы знать некоторые языки необходимо-таки иметь мозги.

                                                                      +1

                                                                      Язык желательно все таки знать. Английский.

                                                                      0
                                                                      С# стабильно в середине, не подвержен кризисам, как экономика в СССР (
                                                                        0

                                                                        Как у него с разработкой и работой под Linux сейчас, можно спокойно брать и работать, а потом деплоить в прод?

                                                                        +1
                                                                        никогда не будет лишним изучить пару тройку языков и быть широкопрофильным специалистом, в этой сфере нельзя стоять на месте, все развивается, от старых вариантов можно отказываться, изучать новые, это позволит всегда быть на максимуме зарплат и востребованности, если же сидеть все время на одном языке и считать что это навечно, увы это не так, но тут даже не увы, а ура, т.к. развитие языков несет все больше интересностей :)
                                                                          0

                                                                          Я думаю пункты 3 и 5 должны быть на самом верху. Я долгое время работал Java и PHP разработчиком, но заинтересовался Rust'ом (когда-то давно у меня был и плюсовый опыт). Года полтора я просто изучал язык, писал на нем хобби-проекты в свободное время, старался активно участвовать в сообществе. Главными тут были — интерес к самому языку, вера в его перспективность и понимание того, зачем он нужен мне в моих личных проектах. Со временем стал неплохо разбираться в нем, и устроиться на работу не составило большого труда. Сейчас работаю Rust-разработчиком и в общем-то всем доволен. Хотя моя зарплата слегка уменьшилась с переходом на Rust, но она все равно осталась выше приведенных тут медианных значений и я получил возможность больше времени уделять тому, что мне нравится.

                                                                            +1

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


                                                                            И я не согласен с Анной Мелеховой: с моей точки зрения мышление определяет язык. Параноик и педант не будет эффективно писать на динамическом языке со слабой типизацией, в то время как противоположный психотип не будет писать на С++/Rust.

                                                                              0
                                                                              Утверждают, что зарплаты в паскале выше, чем в C#, JS и Python
                                                                              www.businessinsider.com/the-top-coding-languages-with-the-highest-salary-2020-4#pascal-is-associated-with-an-average-global-salary-of-6277390-9

                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                              Самое читаемое