HR Digital
129,08
рейтинг
27 декабря 2016 в 11:38

Разработка → Самые востребованные языки программирования 2016

Под конец этого непростого года наша служба исследований собрала двадцатку самых востребованных языков программирования на hh.ru. По каждому языку отдельно посчитали динамику за год. А по первой пятерке заодно посмотрели изменения за 5 лет.

Что произошло: PHP в этом году стал самым востребованным у работодателей, отняв пальму первенства у Java. За год выросли оба, но PHP вырос сильнее. Go и Swift «выстрелили» на 161% и 100% соответственно, хотя до лидеров по количеству вакансий им еще далеко. А вот Python заметно сдал позиции, сразу на 32%.

Если сравнить с индексом TIOBE, то сразу заметно, что PHP у нас заметно выше, а Visual Basic, например, заметно ниже. Go рванул и там и тут, а вот Objective-C у TIOBE в лидерах роста, а у нас он упал на 9%. С у них, кстати, упал сильнее всех, а у нас, наоборот, вырос на 46%.


А где же 1С, спросите вы? В табличку не включили, но если интересно, то все неплохо: 2015 — 9 473, 2016 — 13 735. Прирост: 45%. В абсолютных цифрах — самый востребованный язык.

Это динамика первой пятерки за последние 5 лет в абсолютных значениях количества вакансий. Сильнее всего последний кризис ударил по сегменту PHP, хотя в этом году спрос на этих специалистов полностью восстановился.

Та же пятерка, только динамика в процентах. За пять лет JavaScript вырос сильнее всех.

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

Всем добра, проведите новогодние праздники с родными и друзьями и будьте всегда востребованы на рынке труда!
Автор: @djika

Комментарии (152)

  • +3
    Спасибо, что поиск теперь работает лучше чем год назад, когда на запрос scala выдавалось еще всё со словом scalable. А вакансий субъективно стало наоборот больше.
  • +2
    Удивлен насчет PHP. Не связан ли рост с выходом PHP7?
    • –2

      PHP — это лоукост и кризис, вероятно, привел к тому, что многие компании рассматривают более дешевую разработку (и разработчиков).

      • +4
        Не только, Java и C# это языки большого и серьезного бизнеса (правда Java ещё и язык смартфонов), они использовались в основном для заграничной разработки. С последними событиями, многие компании перевезли разработчиков (гугл и т.п.) в другие страны, в результате за границей вакансий по этим языкам стало больше, а в РФ стало меньше.
        Плюс, с падением курса рубля, программистам на этих языках стало сильно выгоднее работать за границей (или удаленно), что тоже сказывается на рынке разработки. А вот PHP чаще использовался для своих разработок, чем для зарубежных, поэтому он и растет в РФ.
        • 0
          (правда Java ещё и язык смартфонов)

          А на C# мобильную разработку вывезли что ли?
          • 0

            Windows Phone (или Windows Mobile, вроде опять переименовали) и Xamarin даже в сумме не дают сколь бы то ни было большого процента присутствия C# на рынке мобильной разработки.

            • +1
              Тем не менее, мобильная разработка на С# есть, процент присутствия на рынке — другой вопрос.
              Эх… и в карму кто-то минус зарядил…
              • 0

                Так-то мобильная разработка много на чем есть (Python, JS, C++, даже с Ruby что-то было, не считая Kotlin и прочих JVM-языков, на которых пишут под Android в той или иной степени). И вообще в этом мире бывают аномалии — от сайтов на C++ до десктопных приложений на PHP. Но в расчет их никто не берет.
                Карму подровнял, но лучше о ней все же не вспоминать в комментариях :)

                • 0
                  Ваш совет учту, спасибо :)
                • +2
                  до десктопных приложений на PHP

                  Встречал такое один раз. Надо было доработать одно приложение. Но там такой ад был адовый, что в итоге проще оказалось всё на C++/Qt переписать.
      • 0
        Я бы не сказал что PHP разработчики дешевые.
        Хотя разброс в ценах большой.
        У нас люди от 150 работают.

        Компания за счет кризиса поднимается, т.к. многие участники международного booking-broker рынка отвалились и на их место частично свободно.
        • 0
          К слову — при росте спроса на PHP логично предположить рост зарплат и рост предлагаемых денег. Логично что если было 100 вакансий, а стало 200, число разработчиков за год явно в 2 раза не увеличилось, особенно свободных.
      • 0
        Я думаю, что рост PHP также связан с хорошим ростом javascript/css, потому как php для них очень близок. И даже перл подрос. В тоже время как python, который не столько бэкенд, сколько универсал — упал.
    • +2
      Вообще с трудом верю в такаю статистику не только в данные по PHP
    • 0
      Лично в нашей компании это связано с увеличением штата.
      Из-за кризиса освобождает много места, где раньше были конкуренты.
  • +10

    Простите, а что, CSS – уже язык программирования?

    • +2
      Мы отсюда частично исходные данные взяли: 15 самых популярных языков программирования по версии GitHub
      • +4
        «Cascading Style Sheets (каскадные таблицы стилей) — формальный язык описания внешнего вида документа, написанного с использованием языка разметки.»

        «язык описания» != «язык программирования»
        • +1
          Если убрать CSS, то на 18 место попадет язык ассемблера: 15 год — 13 вакансий, 16 год — 16 вакансий.
          • +22
            То есть, CSS здесь лишь для того, чтобы ассемблер не попал в список? О_о
            • 0
              Нет, просто если его убрать, то в рейтинг попадет ассемблер, если судить по количеству вакансий.
              • –1
                We need go deeper =)
              • +1
                А что плохого в том, чтобы язык ассемблера попал в список?
            • +2
              Странно, что XML, JSON или HTML не попали, они куда чаще упоминаются в вакансиях.
              • +2
                XML, JSON или HTML

                Вряд ли есть вакансии чисто по «языку» XML или JSON. Они упоминаются только как доп.навыки. А вот CSS/HTML или SQL вполне могут быть единственным «языком» в вакансии (верстальщик, админ баз данных и т.п.)
                • 0
                  Эм, а вакансии чисто по «языку» CSS, есть!
                  • +1
                    Эм, а вакансии чисто по «языку» CSS, есть!

                    Есть, есть. Разве кто-то с этим спорил? А вот вакансий XML-Developer или JSON-Developer скорее всего нет или их очень мало (ИМХО)
                • –2
                  SQL и CSS совершенно разного уровня вещи. И SQL это язык запросов, а не программирования, уж если на то пошло.
                  • +2
                    И SQL это язык запросов, а не программирования, уж если на то пошло.

                    Это вопрос терминологии. SQL — тьюринг полный, а значит он не менее ЯП, чем, скажем, Brainfuck. В вики SQL указывается как функциональный узкоспецилизированный ЯП, в принципе языки запросов и языки программирование это не исключающие друг друга множества. А всякие расширения, типа PL-SQL или Transact-SQL тем более могут считаться ЯП.
                    • 0
                      Кто же спорит-то? Но CSS тут рядом поставить сложно, как не крути.
                      • 0
                        Возможно к CSS относят различные less, sass и прочие генераторы.
        • +3
          SQL вроде бы даже тьюринг полный, разве нет?
          • 0
      • +2
        На Гитхаб все же преобладает Опенсорс, соответственно, все ПО компонентного типа (Delphi, Powerbuilder, частично .NET) или с коммерческими библиотеками, будет в статистике сильно страдать.

        Возможно, стоит чуть шире глянуть своей статистики по вакансиям, не ограничиваясь топ-15 по гитхабу?
        • 0
          Ну вот у меня репозитории по делфи все на bitbucket и большая часть их приватная. Статистика — дело неблагодарное.
        • 0
          Вся коммерция сидит на приватных системах контроля версий. Куча вакансий, где нужны знания VSS, SVN, а про гит там даже не думают. Поэтому с вами согласен. Строить статистику языков, предварительно отфильтровав их по другой статистике, уже не правильно. Также можно было предварительно отсеивать языки, по отзывам CSS сообщества.
          • 0
            приватно можно и на git все поднять. на одной фирме мы использовали gitlab виртуалку от bitnami, на другой — TFS + git.
            в обоих случаях под .NET инфраструктуру. git настолько удобнее vss и svn, что сейчас, думаю, больше проектов переводят на него.
    • 0
      А SQL?
      • –3

        Это язык запросов к БД. Тоже не язык программирования. И Oracle там… Это ж фирма. В общем, как-то нет доверия к этому списку языков...

        • 0
          На абсолютную истину мы не претендуем, но на рынке существенное количество вакансий вроде «Разработчик Oracle» или «Программист SQL». Поэтому мы посчитали уместным включить их в наш список.
        • +4

          Вы слишком педантичны.


          Для любого неспециалиста "язык программирования = формальный язык". Uml, rapide, vrml и verilog" вполне идут в ту же категорию.

      • +1
        У многих вендоров СУБД есть свои процедурные расширения SQL.
    • +1
      Так же как и Oracle
      • +1
        HR при составлении вакансии не разбирается в терминологии. Под строчкой Oracle обычно скрывается PL\sql + вагоном sql, часто с java. PL\SQL самый что ни на есть ЯП.
    • –2
      CSS это декларативный язык программирования.
      https://en.wikipedia.org/wiki/Style_sheet_language — «A style sheet language, or style language, is a computer language that expresses the presentation of structured documents. ».
  • +5
    Интересно было бы увидеть привязку зарплат к языкам с детализацией по опыту.
    И ещё статистику отдельный язык/технология/стэк
  • +11
    А где же 1С, спросите вы?

    Нет, не спросим...

    • +2
      а я все же спрошу, а почему исключили? какие-то объективные причины фильтрации хотелось бы услышать
      • +1
        1C — это какая то Дич!)
        • +4
          ну вот это субъективно. По мнению многих, лидер PHP, та ещё дичь
          • 0
            Ну это я в шутку!)
            Мой преподаватель в вузе вообще говорил что PHP язык для собак!) Но я разработчик именно на PHP (ну не только) и сейчас работаю у него в компании на должности PHP разработчика)
            • +2
              Научить собаку программировать. О_оВаш учитель — великий человек.

              Извините, не удержался.
              • –1
                С PHP и такое возможно, он в конце-концов специально для этого и создавался! Эх, гордость за страну берёт, на Павлове-то величие оказывается не закончилось!
          • 0
            Почему-то, если с этими «многими» начинать беседовать глубже, выясняется, что они понятия не имеют, что такое современный PHP.
            • 0

              Точно так же как если бы взять разработчика на "современном PHP" и попытаться рассказать что такое "современная серверная разработка на javascript". Когда говоришь что там уже есть async/await обычно кислая мина сменяется заинтересованностью.

              • 0

                Можете пояснить зачем разработчику на современном PHP конструкции типа async/await? PHP сам по себе работает основываясь на совершенно другой парадигме.


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


                Чтобы было понятно, PHP — это DSL, который идеально подходит для своей ниши, но возможностей при этом дает даже больше чем нужно (расскажите, есть ли в "современном JavaScript", например, ORM уровня Doctrine2?)

                • 0
                  Можете пояснить зачем разработчику на современном PHP конструкции типа async/await?

                  Что бы не городить ворох колбэков и промисов. Да, есть корутины, можно строить на них (пример — amphp) но это все же не так вкусно. В php internals дискуссия о том что надо вводить async/await не так давно была и к версии 8 надеюсь реализуют.


                  Если вы говорите что "ниша php только в сайтиках" то я с вами не соглашусь. А если "ниша php только в web" то сегодня есть огромный пласт задач, для которых старая модель выполнения по принципу "повар приготовил повар умер" крайне не эффективна.


                  Да, есть проекты вроде FastCGIDaemon или php-pm которые частично решают проблему бутстраппинга приложений (когда можно время респонса symfony + doctrine уменьшить с 20ms до 10ms). Но когда речь идет об асинхронной работе (очереди, pub/sub, много работы с I/O) то тут уже совсем грустно порой становится. У меня к примеру есть один компонент в системе который вынужден на каждый запрос стучаться по сети в отдельную хрень. И пока он стучится сервер ждет а не пробует обработать другой запрос.


                  В целом же если брать конкретно саму конструкцию, async/await резко понижает порог вхождения в разработку систем использующих event loop. То есть по сути средний php разработчик сможет писать все те же макароны в том же стиле но выполняться это все будет куда эффективнее.


                  Чтобы было понятно, PHP — это DSL, который идеально подходит для своей ниши

                  Чтобы было понятно, это не DSL ни разу. Это General-Purpose Language. GPL с ограниченной областью применения не делает этот GPL DSL-ем.


                  но возможностей при этом дает даже больше чем нужно

                  а что нужно? для сайтиков нода неплохо справляется. Да и сегодня намного проще бывает заставить на сервере рендрить какой-нибудь react app вместо того чтобы городить php+twig. Это банально эффективнее с экономической точки зрения (вопросы менеджмента и распараллеливания). Если же сфера php low-end сегмент рынка web разработки (вордпресс если проще) — то может быть. И то неизвестно сколько еще это продлится.


                  ORM уровня Doctrine2?)

                  TypeORM для TypeScript (мы же хотим быть type safe на бэкэнде, чего php нам к слову не дает). Оно конечно еще сырое и к продакшену не годится, но это весьма активно развивающийся проект. Зато в JS есть WeakMap который намного удобнее для построения того же identity map. Да, weak map есть и для php но доктрина его не умеет по понятным причинам.


                  Да и опять же, не ORM свет един:


                  • хотите table gateway/dao — все есть (мне лично нравится knex но есть и другие варианты)
                  • хотите active record — все есть
                  • хотите оперировать агрегатами сущностей как в доктрине но не хотите реляционных ограничений — mongodb
                  • написать гидраторы для сущностей, identity map и unit of work (не универсальный под все а специализированный) — не сильно сложная задача. Заворачиваем все это в репозиторий и готова наша личная ORM без магии. Хотим магии — заворачиваем все в Proxy. Но лучше дождаться TypeORM.

                  Смею утверждать как разработчик, имеющий 90% времени дело с Symfony + Doctrine2 что для проектов где этот стэк хорошо подходит, жать начинает уже PHP. Если в PHP добавят generics то может быть я стану меньше ныть.

                  • 0
                    Что бы не городить ворох колбэков и промисов. Да, есть корутины, можно строить на них (пример — amphp) но это все же не так вкусно. В php internals дискуссия о том что надо вводить async/await не так давно была и к версии 8 надеюсь реализуют.

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


                    Я-то прекрасно понимаю зачем это нужно, и более того могу напомнить что к примеру во фреймворке Twisted (Python), паттерн reactor (наряду с Deferred) был реализован еще тогда, когда того же jQuery даже в проекте не было, уж не говоря о NodeJS (14 лет назад).


                    И все кому надо было этим пользовались (синтаксиса async/await еще тогда не было, но была возможность использовать синтаксис генераторов — yield).


                    Чтобы было понятно, это не DSL ни разу. Это General-Purpose Language. GPL с ограниченной областью применения не делает этот GPL DSL-ем.

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


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


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


                    Но здесь нужно понимать, что задачи все-таки бывают разными, и молотком бревна не распилишь: осознание этого факта почему-то не ввергает плотников в ужас =)


                    а что нужно? для сайтиков нода неплохо справляется. Да и сегодня намного проще бывает заставить на сервере рендрить какой-нибудь react app вместо того чтобы городить php+twig. Это банально эффективнее с экономической точки зрения

                    Однако PHP судя по графику все еще не только не умер, но и живее всех живых


                    TypeORM для TypeScript (мы же хотим быть type safe на бэкэнде, чего php нам к слову не дает).

                    Когда будет production-ready и будет поддерживать, к примеру, Table Inheritance, тогда можно будет о чем-то разговаривать (напомню что сегодня почти 2017 год на дворе).
                    К тому-же это не JavaScript, а TypeScript.


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

                  • 0
                    Простите, но я не понял: каким образом у вас получается 20ms на symfony+doctrine? Звучит нереально.
                    • 0

                      Я рассматривал типичные запросы на чтение, вроде "получить список категорий" или "список продуктов в каталоге". Тут самое "жрущее" это инициализация контейнера и гидрация данных (из 20ms ~8 будет занимать та самая гидрация). Причем в зависимости от сложности время на гидрацию будет меняться. Иногда даже проще сделать 2 sql запроса без джойна что бы уменьшить время гидрации.


                      Причем немало времени уходит на добавление сущностей в UoW… чего можно избежать. Или еще круче — можно заюзать ArrayHydrator и получить оверхэд всего в пару милисекунд.


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


                      Конечно же это с скомпилированным контейнером, настроенным opcache (не дефолтные настройки), кэшированием метаданных доктрины в apcu и т.д. Пару процентов подарило недавнее обновление composer.


                      Какое-нибудь добавление того же продукта будет занимать времени уже побольше (тут ресурсы начинает жрать UoW). Хотя это всеравно не так страшно, если вы страшного ничего не делаете.


                      Симфони в продакшен окружении весьма шустрая штука, да, некоторые вещи там откровенно медленны. И да, есть вещи которые, если о них не знать, резко сказываются на производительности. Но ничего сверхъестественного в этом нет с учетом что приложение на nodejs будет отдавать примерно те же json-ки за пару милисекунд.

                • –1

                  А какой уровень этой ORM? С Hibernate сравнится? А по каким параметрам сравнивать?..
                  Вот интересный вы человек… как оценивать-то?


                  PS пренебрежительное отношение к PHP и девелоперам на нём связано с несколькими факторами:


                  • очень низкий порог входа… порождает дичайшее количество говнокодеров и велосипедистов
                  • исторически сложившееся отношение на пике популярности языка (я с ним не работал уже больше 5 лет, на тот момент он имел отвратительную архитектуру и страшное количество грабель, на которые легко наступить)
                  • сессионность (я не знаю, как можно работать с языком, который не имеет состояния… нет на уровне простеньких скриптов — всё понятно… но загружаться сложный движок?!..)
                  • по вкусу — каждый знает лично ему неприятные элементы языка
                  • 0
                    А какой уровень этой ORM? С Hibernate сравнится? А по каким параметрам сравнивать?..
                    Вот интересный вы человек… как оценивать-то?

                    Вообще-то Doctrine во многом вдохновлялась именно Hibernate. Вы не знали этого?


                    А по каким параметрам сравнивать?

                    По реализованным паттернам и поддерживаемым фичам. Непонятно даже откуда такой вопрос взялся.


                    PS пренебрежительное отношение к PHP и девелоперам на нём связано с несколькими факторами

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


                    И да, на PHP не пишут серьезный банковский софт, т.к. PHP для этого не создавался и в этой нише есть свои лидирующие технологии.

                    • 0
                      Вообще-то Doctrine во многом вдохновлялась именно Hibernate. Вы не знали этого?
                      По реализованным паттернам и поддерживаемым фичам. Непонятно даже откуда такой вопрос взялся.

                      Вопрос взялся от того, что вы, приводя пример, заявились как разбирающийся в библиотеке человек. Мне для того же — потребуется существенное время (вернуться в php, разобраться с Doctrine и т.д.). Ну и основываясь на ваших ответах, которые предполагают, что вы разбираетесь в технологии — можете сравнить Hibernate и Doctrine?


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

                      Мой опыт общения с кодом на php и взаимодействия с проектом, реализуемым сторонней командой на php говорит иначе. Низкая квалификация и массовый говнокод даёт много-много радости при попытке заинтегрироваться (и ещё больше при переносе части функционала из php в java)...


                      PS это не означает, что я не видел лапшу или говнокод на java… Но сама java мешает говнокодить так же сильно, как это возможно на php.

                      • 0
                        можете сравнить Hibernate и Doctrine?

                        Doctrine недотягивает до Hibernate по ряду фич, но впереди релиз 3-ей версии и они там пошли чуть по другому пути. Хотя для моделирования предметной области все что надо с большего есть. В частности года 2 назад появились Embeddable объекты для VO и т.д. Работать с коллекциями довольно удобно...


                        То есть я бы сказал что с этим в PHP комьюнити неплохо и можно строить реально сложные приложения. НО… пользоваться доктриной умеет… не такое большое количество людей. Подавляющее большинство PHP разработчиков в принципе используют процедурное программирование с классами, ActiveRecord/Row Gateway/Table Gateway и живут не тужат. Даже те кто юзают доктрину используют ее в лучшем случае как Row Data Gateway а не как полноценную ORM. Многие даже не пытались разбираться с концепциями вроде unit of work и продолжают персистить сущности при обновлении не понимая что делают.


                        Лично мне Java не нравится, просто субъективное чувство. Вот Kotlin — он прекрасен.


                        Низкая квалификация и массовый говнокод даёт много-много радости при попытке заинтегрироваться (и ещё больше при переносе части функционала из php в java)...

                        Есть такая проблема. Во многом она вызвана тем, что получить какой-то результат в PHP намного проще и быстрее чем в Java.


                        Получаем результат -> радуемся -> эффект Даннинга Крюгера -> работаем дальше и вырабатываем привычку работать как получается -> напарываемся на проблему которую "как обычно" решить не удается и нужно развиваться и понимаем что напоролись на непреодолимую стену. А работать надо. А времени учиться нет. В итоге многие просто остаются на том уровне. Часть медленно ползет по стеночке.


                        НО если разработчику в начале пути повезет с командой можно расчитывать что он не будет ждать а будет развиваться более планомерно. Другое дело что в PHP комьюнити это скорее редкость.


                        Это мои личные наблюдения которые я вывел из общения с большим количеством PHP разработчиков.


                        Еще есть очень интересная штука… Из-за вот этого разделения на "php-ники и все остальные" отрыв между комьюнити становится больше, идеи и практики из других комьюнити сложнее проникают в php (банально психология людей). Как часто можно услышать при обсуждении очередной RFC по дженерикам "не делайте java из PHP". Люди не понимают профит от этих изменений и не хотят понимать, потому что у них уже негативное восприятие связанное с тем что джависты их гнобят.

                        • 0
                          Есть такая проблема. Во многом она вызвана тем, что получить какой-то результат в PHP намного проще и быстрее чем в Java.
                          Получаем результат -> радуемся -> эффект Даннинга Крюгера -> работаем дальше и вырабатываем привычку работать как получается -> напарываемся на проблему которую "как обычно" решить не удается и нужно развиваться и понимаем что напоролись на непреодолимую стену. А работать надо. А времени учиться нет. В итоге многие просто остаются на том уровне. Часть медленно ползет по стеночке.

                          Ну вот это вот и приводит к


                          Из-за вот этого разделения на "php-ники и все остальные"

                          Ну а дальше — по накатанной.
                          Т.е. проблема изначально в более низком базовом уровне, который заставляет резко расти разрыв уровней между разработчиками в разных языках. Аналогичной проблемы нет между языками java, c#, c++ и прочими (впрочем там есть другие проблемы… но они всё же не настолько остры). Что интересно, разрыв js <-> прочие аналогичен разрыву php <-> прочие, но js имеет свою уникальную экосистему, в которой может работать только он (прочие языки вынуждены транспилироваться/компилироваться в js), а php такой сферы не имеет. За счёт этого в js-мир нередко уходят люди с практиками из других языков. Отсюда страшный кавардак в FE, но при этом там происходит существенное развитие и об этом знают "в остальном мире". Про изменения в мире php в курсе в основном программисты php. И если сам язык и инструменты начинают подтягиваться к остальным по возможностям, то вот комьюнити на текущий момент (имхо) отстаёт.

      • 0
        Не исключили, добавили же под таблицей :)
        • 0
          перефразирую вопрос.
          Почему PHP в табличке, а 1С под табличкой, а не наоборот?
          • +2
            А его можно назвать самостоятельным ЯП? Не очень с ним знаком, но он же вроде не может выполняться без самой 1С, да?
            • +3
              Кто-то мне говорил, что и С без компилятора так себе работает.
            • 0
              Нет. Его можно применять и без платформы 1С — oscript.io
              Хотя вы правы — ему нет место в одной таблице с CSS :)
            • +1
              Странный аргумент. Java не может выполняться без JVM, Python не может выполняться без интерпретатора и тд.
            • 0
              А есть ЯП, который может выполняться без интерпретатора/компилятора/среды?
              • +1
                Ну… машинный код нормально так работает…
                • 0

                  Не может выполняться без процессора.

                  • 0
                    Так любой код не может выполнятся без процессора. Вопрос был про интерпретатор/компилятор/среду.
                    • 0
                      Генетический код считается? )
                      • +1
                        Генетический код выполняется в специальной клеточной среде-интерпретаторе.
                • 0
                  То есть, только машинный код можно назвать настоящим ЯП? А все остальные? Является ли процессор средой исполнения, учитывая что машинный код всё же не прямая подача тока на ножки, а тоже уровень абстракции? Справедливо ли перефразирование аргумента «но он же вроде не может выполняться без самой 1С» как «но он же вроде не может выполняться без самого процессора»?
              • –1
                Среда 1с как-то не тоже самое что jvm, например. Не могу точно сказать, в чем именно разница, но она имхо есть)
                • –1
                  Можно выразить несогласие словами?
                  • 0
                    На самом деле, проблема скорее в том что многие кто называется 1С программистами, на самом языке почти не работают, а по сути просто настраивают конфигурацию самой программы 1С.
                    • –1
                      Это заблуждение
                • 0
                  Платформа 1с изначально была заточена под специфические задачи. Сначала это была задача по автоматизации бухгалтерского учета. Далее она развивалась и расширялась с учетом пожеланий возникающих у ее пользователей, а функционал расширялся.

                  Согласитесь ведь, что сейчас мало кому придет в голову писать сайт с нуля на ассемблере или даже на си? Будут использовать набор технологий заточенных специально под это php+html+javaScript+css+mysql, скорее всего возьмут готовый шаблон и движок сайта и переделают под нужды заказчика.

                  Так же все обстоит и с 1с, ее используют для решения определенного круга задач.
    • –7
      завидовать плохо :)
  • +1
    А теперь предлагаю сравнить с трендами гугла. Например PHP с медленно но верно теряет популярность последние 10 лет.
    • +3
      Ну, одно дело мировой рынок вакансий и другое локальный рынок труда РФ. В связи с кризисом крупному бизнесу в РФ может быть не до обновления ПО, а из-за санкций компании-аутсорсеры перевозят разработку в другие страны. А вот сайты всем нужны в любое время, отсюда языки «энтерпайза» стали менее популярны. Если смотреть фриланс биржи в РФ, то по Java мало проектов, а по PHP до фига, за рубежом скорее наоборот.
    • 0
      Интересно, почему так. Добавил в графики Java и JavaScript, они тоже падают. Разве что JS устаканился в последние годы.
      https://www.google.com/trends/explore?date=all&q=%2Fm%2F060kv,%2Fm%2F07sbkfb,%2Fm%2F02p97

      Может гугл изменил алгоритмы?
    • 0

      У вас есть данные в абсолютных цифрах?


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


      Вы это все учли, когда "предлагали"?

  • +2
    В даунсайзерах кроме древнего бейсика, функциональные языки. В кризис не до абстрактной эзотерики — работу работать надо.

    А с Питона, похоже мигрировали в ПХП.
    • 0
      Присоединяюсь к вопросу по семейству Pascal/Delphi.
    • +3

      Ну почему, хаскель вот вырос на 800%.

  • +1

    Странно, что ни в каком виде нет Паскаля. Я думал, ещё не все дельфисты пропали. CodeGear-то жив, вроде.

    • –2
      Да, вы правы, Delphi стоило бы включить на 9 место.
      Delphi:
      2015 — 709 вакансий
      2016 — 923 вакансии
      • +4
        А поясните, пожалуйста, что значит «стоило бы?»
        Разве это не топ-20 самых востребованных языков программирования за 2016 год?

        Судя по описанию это достаточно фиксированный список, который зависит только от количества вакансий. И он не должен зависеть от какой-либо вольности в трактовках.

        Да, можно поспорить насчёт SQL.
        Да, Вы не включили в список 1С, но хотя бы сразу написали об этом.

        Но похоже, что есть ещё языки, которые также оказались в немилости и были пропущены. Если это так, то ИМХО список как-то теряет весь вложенный смысл.

        Статистика бесполезна, если она неверна.
        • –1
          Суть в том, что нужно было иметь отправную точку для анализа. Мы взяли Github и TIOBE. Двадцатка строилась, как вы видите на основе количества вакансий. Стоило, потому что его не включили, хотя количество вакансий заметное.

          Польза, на мой взгляд, не в конкретном месте языка, это же не «писькомерка», не соревнование, а в количестве вакансий за 15 и 16 год, чтобы оценить реальный спрос рынка на таких специалистов. Ну и в динамике первой пятерки за 5 лет, чтобы попробовать понять, как разные события влияют на спрос — это интереснее, чем место само по себе.
          • +2
            А чем плох список из _всех_ языков программирования? Ну, знаете, совсем всех. И по ним уже выбрать топ-20 или сколько там, по вакансиям?
          • 0
            Ну я, глядя на ваш список, подумал что Delphi всё.
            • –1
              Из-за таких статей, большинство думает, что она умерла. Но мы же с вами знаем правду.
          • +2
            Тогда не называйте это ни «самые востребованные языки», ни «топ-20».

            Неужели непонятно, что своим названием Вы утверждаете, что это языки находятся на первых N-позициях?

            А в реальности может окажется, что это языки с 5 до 25 место, потому что первые 5 языков Вам не понравились.
    • +1
      Я искал работу пару месяцев назад (Delphi + SQL), желающих нанять было очень много. Предложения были с весьма достойной заработной платой. Поэтому я тоже удивился, не увидев тут родную Delphi. Но больше всего удивился читая комментарии, что вместо CSS хотят вставить ассемблер.

      Зато в этой статистике есть Delphi https://habrahabr.ru/company/kingservers/blog/307012/
      • 0
        Делфисты ещё ладно. А что делать их братьям по борланду — Билдеристам? (C++ Builder).
        На делфях пишут много больших проектов (от файловых менеджеров и плееров музыки до SCADA-систем). А вот про Builder как-то непонятно. Он вроде есть и, вроде почти делфи, но где все эти люди?
        Везде, где упоминается C++, обычно имеется в виду что угодно, но только не Builder.
        • 0
          Честно говоря, я совсем и забыл о существовании C++ Builder. У меня куча знакомых программистов которые пишут на многих языках, но что бы кто-то писал на C++ Builder, не слышал. Видать и правда, они где-то прячутся.
        • 0
          Всё таки билдеристы — это гораздо ближе к C++, чем к Дельфи, несмотря на то, что сейчас они в одной студии поставляются (RAD studio), прямо как у Майкрософт — одна ide — любой язык. А вообще в последней RAD Studio их C++ компилятор вроде как на основе CLANG'а сделан, т.е. все современные плюшки C++ поддерживает.
          • 0
            Ух ты ж жесть какая, залез на википедию, узнать не наврал ли где я, и узнал, что был ещё C# Builder.
            Borland Developer Studio 2006 — единственный полноценный комплект, содержащий Delphi, C++ Builder и C# Builder.
    • +1
      CodeGear тут не при чём. Делфи давно уже была у embarcadero, а сейчас уже год как собственность Idera.
      Но да, делфистов еще много живых ))
  • 0
    Однако интересно что самый большой рост у Go — 161%
    • +4
      эффект низкой базы, ну что вы как маленький
  • 0
    удален
  • +3

    Какая-то бесполезная, по-моему, статистика. Где данные по средней предлагаемой зарплате по этим востребованным языкам? Предположу, что массово требуются программисты PHP на низкую зарплату. 1C, Obj-С, Java изначально требуют более высокого уровня, поэтому вакансий меньше и они, скорее всего, дороже.

    • +2
      Статистика по количеству вакансий, в рамках этой задачи цели по зарплатной статистике не было. Это тоже интересно, тоже можно сделать, но тут про вакансии, то есть спрос :)
  • +10

    Какое это имеет отношение к блогам^Wхабам "программирование" и "C++" (а заодно "JavaScript" и "PHP") и потоку "Разработка"? Топайте в свой "Маркетинг" или куда-нибудь ещё.


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

  • +1
    Рост вакансий по языкам сам по себе любопытен, но, увы, не отражает изменения баланса между языками.

    Не могли бы вы посчитать не рост вакансий вообще, а либо рост/падение доли вакансий каждого языка в общей массе (например, php = было 5404/sum(2015), стало 9707/sum(2016), прирост = …), либо прирост каждго языка относительно прироста рынка в целом (например, php +79%, но все языки вместе взятые +50%, а, значит, php лишь +29%)?
  • 0

    Хитрецы блин. Когда ЗАО "1С" выпускает интеграцию с hh.ru в ЗУП 3.0 — они официально об этом пишут на сайте.
    А вы так скромно под табличкой.


    http://v8.1c.ru/hrm/kadrovoe_planirovanie/vakansii.htm


    В абсолютных цифрах — самый востребованный язык

    а то мы не знали ;-)


    P.S. GoLang порадовал

  • 0
    У меня по личномы опыту — Питон растет с каждым днем как на дрожжах, я бы ему 1-ое место дал бы по росту
    • +2
      У меня по личному опыту — .net растет с каждым днем как на дрожжах, я бы ему 1-ое место дал бы по росту.
      Каждый кулик…
      • 0
        .NET довольно востребуемый язык (к слову С# это мой основной язык). Но в последнее время с кем не говорю — переходят или уже перешли на Питон. язык прост как пареная репа, кросс-платформа и куча готовых библиотек — в этом его секрет
        • 0
          А переходят с чего и для каких целей? Я как не особо из мира питона, но интересующийся ml, вижу что у него очень развита экосистема для data science и machine learning, многие вещи стандарт де-факто.
          • 0
            Сами же и ответели, сейчас ML + DScience — все очень модно… я бы сказал на нереальном подьеме в любой фирме которая занимается мало-мальски R&D
        • 0
          язык прост как пареная репа, кросс-платформа и куча готовых библиотек

          И кстати, под это определение прекрасно подходит java, почему не на нее?
          • 0
            java? IMHO java сложнее на порядок :)
    • +3

      А в моём личном опыте все вокруг на расте пишут, и что? Его даже в топе пока нет

      • –3
        Про RUST я даже и не слышал, я работаю с огромным количеством разных команд и фирм :P
  • +1
    Так я не понял, а где Паскаль? Помоему самый топовый язык!
  • 0
    А можно узнать больше деталей про сбор статистики? Я замечал, что компании несколько вакансий на одну позицию открывали, но с разными заголовками и ЗП.
  • +1
    Странно что в списках нет языка Rust. Не очень репрезентативный список imho.
    • 0

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

  • +1
    Было бы очень интересно увидеть динамику питона за пятилетку.
  • +1

    Как эта статистика собирается?


    Я пытался подобную статистику из поиска извлечь, но возникало много вопросов. Например для C# вакансии иногда не содержат C#, а содержат .NET. Часто в вакансиях более одного языка, особенно заметно на результатах поиска C++.


    JavaScript вообще в каждой второй присутствует.


    У вас есть способ получения "основного языка программирования" из вакансий или вы также на результаты поиска смотрите?

  • 0

    Интересно, кому нужен SAS, на котором я пишу… Уверен, что числа будут небольшие.

  • 0
    Почему нет зарплат?

  • –1

    Люблю в конце года смотреть на рейтинги ЯП. Особенно радует то, что популярность Си не падает и более того возрастает.

  • –2
    Здесь немодно так писать. А если еще и напомнить, кто царь горы по скорости, еще и в карму можно отхватить =)
    • +2
      А если еще и напомнить, кто царь горы по скорости

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

      По скорости разработки… точно не Си.

      P.S. Си имеет свои область там где ассемблер слишком долго, а более высокоуровневый язык (даже С++) слишком медленно, но не стоит делать из него серебряную пулю или золотой молоток. Тем более что всякие Rust'ы, D, Go и т.п. переодически пытаются откусить от пирога C/C++.

      • –1
        По определению быстрее него и прямых рук ничего быть не может.

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


        Вывод, если мы возьмем подавляющее большинство разработчиков то вариант на Си будет быстрее. Остальные могут просто быть такими же быстрыми (например rust на части задач по производительности будет таким же как Си).


        По скорости разработки… точно не Си.

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


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

        • +2
          И ребята которые пилят GCC могут похвастаться подобными знаниями и ровностью рук. То есть GCC будет генерить вам более эффективный код нежели вы напишите руками. Вывод, если мы возьмем подавляющее большинство разработчиков то вариант на Си будет быстрее.

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

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

          Поэтому вывод неверен: без прямых рук и ассемблер и С могут быть медленнее прочих языков.
          • –1
            Не надо смешивать язык и библиотеки (веб, многопоточка), причем нет разницы, если библиотека является частью языка.

            Go, Rust и даже скорее D(поскольку шаблоны) могут быть равными по скорости С++, но .NET и Java — только на бумаге и в простых тестах (или когда библиотечный код превалирует). Пока что

            • +2
              .NET и Java — только на бумаге и в простых тестах (или когда библиотечный код превалирует). Пока что

              У С# и Java есть возможность компиляции в машинный код напрямую, учитывая оптимизации компиляторов и итераторов тут все неоднозначно. Может быть ситуация автоматически оптимизированный код будет более оптимальным.
              • 0
                Это «бумажная» возможность, пока не применимая на практике.

                Можем протестировать примеры, если покажете. Лично я заинтересован в C#, а в Яве из-за широкого использования рефлексии считаю подобную перспективу нереальной.
                • +2
                  а в Яве из-за широкого использования рефлексии считаю подобную перспективу нереальной

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

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

                  Можем протестировать примеры, если покажете

                  Да на здоровье:

                  1. Native Compilation Tools
                  2. Excelsior JET
                  3. JWrapper

                  Это «бумажная» возможность, пока не применимая на практике.

                  В Java это вполне коммерческие продукты за которые платят хорошие деньги.
                  • 0
                    Да нет, не спутал

                    Эксельсиор — жутко дорогой, забыл по него
                    Jwrapper — это вообще не компилятор, а упаковщик исполнимого байткода вместе с JRE,
                    читаю про JServer Accelerator — так там вообще мрак и Оракл 8й версии

                    Про NET нет вариантов (точнее еще NET Native не готов)
                    Вы это пробовали лично?
                    • +1
                      Да нет, не спутал

                      Рефлексия в Java не меняет байт код, она меняет объекты классов. Объекты классов лежат в памяти и представляют обычные структуры данных. В терминах Си она сохраняет указатели на поля и методы объектов классов и позволяет обратиться в полю или методу по указателю. Ничего такого что нельзя было сделать на чистом С++.

                      По вашей ссылки на вики видно что рефлексия прекрасно существует и в компилированных языках.

                      Вы это пробовали лично?

                      Был опыт использования Эксельсиор'а
                      • 0
                        Не так все просто с рефлексией, RTTI недостаточно.

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

                        Примерно то же пишет и Микрософт с ограничениями Net Native
                        • +2
                          Тот же сайт Эксельсиора честно пишет — что с класслоадером используется обычная JIT-технология.

                          Ещё раз какое отношение ClassLoader имеет к Reflection API? Это никак не связанные в Java вещи. ClassLoader служит для загрузки новых классов, Reflection для изменения объектов существующих классов. Они вообще не связаны. Кастомные ClassLoader в Java используются редко, так это крайне небезопасно и вообще сильный хак.
                          • 0
                            Рефлексия это динамическое изменение программы. Класслоадер — просто частный случай — способ реализации одной из сторон рефлексии.
                            • +2
                              Это вопрос терминологии, но важен тот факт что рефлексия в Java часто используется для получения данных об объектах, но редко для изменения кода. Более того некоторые из реализаций Java (например, Java в Android) вообще не имеют возможности изменения байт кода. Поэтому рефлексия в Java не мешает реализации машинной компиляции.
            • 0

              Rust в целом не особо уступает C. Там конечно есть свои особенности и тикеты в трекере с пометкой slow, но они постепенно закрываются.


              но .NET и Java — только на бумаге и в простых тестах (или когда библиотечный код превалирует). Пока что

              Опять же смотря что брать и как мерять. JIT оптимизирует только горячий код, и делает это в случае с JVM весьма эффективно. Да, есть нюансы, но JVM в последних версиях вроде как умеет и циклы разворачивать сама и векторизацию вычислений. Так что… Все относительно и зависит от задачи. Ну и опять же, мы можем реализовать на Си те 1% кода которые являются батлнеком на худой конец.

              • 0
                В JVM великолепный оптимизатор.

                Единственное, что он не может — это разумно использовать память.

                И тут то самое интересный корень проблем.
        • 0
          По определению быстрее него и прямых рук ничего быть не может.


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


          Поддержу, прямые руки — условие обязательное, но не достаточное. Вот не так давно натолкнулся на код «крутого ассемблерщика»:
          void MemZero(void* ptr_, int size_)
          {
          	__asm
          	{
          		cld
          			mov edi,ptr_
          			xor eax,eax
          			mov ecx,size_
          			rep stosb
          	}
          }
          

          Надо ли говорить, что после замены этого велосипеда на обыйный memset(ptr_, 0, size_); производительность функции сильно возросла (в случае SSE аж по 128 бит за раз обнуляется). И таких примеров было не мало.
          Где-то также на побайтовый самопальный memCpy натыкался, реализованный другим умельцем на ассемблере (так же быстрее!). Когда ему открыли глаза, что современные реализации memcpy (даже не надо ipp'шные функции использовать, всё уже доступно из коробке в майкрософтсом CRT) могут копировать из памяти в память даже не помещая это в регистры, человек отмазался «ну не буду же я делать разные реализации одной функции».
          Третий ассемблерный умелец, нагородил свой велосипед для синхронизации (что-то типа бесконечного спин лока на InterlockCmpExch), за 15 минут так и не разобрался как там работает, пришлось на CCriticalSection менять (не пинайте, VS2005 не поддерживала std::mutex).
          В общем если бы не четвёртый сишник с прямыми руками, который хорошо на ассемблере писал, то моя вера в ассемблерщиков была бы полностью подорвана.
          Ещё, кстати, хороший пример ручной оптимизации на ассемблере — это библиотеки типа ffmpeg. Если компилировать с ассемблерными вставками, то сразу + 30% к производительности, по сравнению с сишной версией скомпиленной интеловским же компилятором.

          В общем моё мнение, что что-то на ассемблере можно сделать быстрее чем, на C, но в реальности на ассемблере часто делают медленнее, чем даже на C можно сделать. Например, то же копирование на C запросто можно не побайтого, а по 8 байт сделать за раз. Но в критическом коде без ассемблера тоже не всегда обойтись. Например, была у нас 2005ая студия, и её реализация CRT memcpy ничего не знала о movntdq, и копирование тормозило. Тут надо было решаться, или переходить на новую студию, либо писать свой самопальный memcpy с movntdq с fallback'ом на movdqa.
          • 0
            Ну так дело то не в том, что Си быстрее или медленнее в данном случае =)

            А сравниваются две ассемблерные реализации — поскольку все Сишные (да и не только Сишные) интринсики (intrinsics) написаны на ассемблере.

            Просто не надо велосипедить, надо брать вылизанные библиотеки.
            • 0
              Ну как бы я пытался 2 мысли донести, про ассемблер ничего плохого не говорил:
              1) [очевидная истина, можно ассемблершик и сишник заменить почти любыми другими] если у ассемблерщика кривые руки, то он в большей части случае напишет хуже, чем сишник с прямыми руками.
              2) [поддерживал предыдущего комментатора, про необходимость досконально знать нюансов платформы, под которую надо писать код ] даже если у ассемблерщика руки вроде как прямые, но он застрял в 90-х (с таблицами сколько тактов выполняются mmx инструкции на pentium 2), то такой тоже ничего хорошего не напишет в современных реалиях. Кстати ещё один случай вспомнился, как мне ассемблерщик доказывал что никак его код не мог замедлить программу. Так ему не понравился сгенеренный компилятор код и он решил написать свою реализацию на ассемблере. Ему тогда не понравился div, и он цитировал что-то вроде «Так, для 386-процессоров выполнение деления на двойное слово требует 38 тактов процессора, на слово — 22 такта, на байт — 14 тактов.». Пришлось ему найти спеку на современные интеловские процы, в которых div занимает 1 такт. Да и вообще, сейчас с конвейерами в процессорах уже никогда нельзя быть точно уверенным сколько тактов займёт та или иная ассемблерная команда, только прицениться на лучший и худший случаи. Поэтому у меня и вызывают уважение парни из ffmpeg'а или наши интеловцы из Нижнего, которые ipp пишут.
      • 0
        а более высокоуровневый язык (даже С++) слишком медленно

        C++ сам по себе не может быть медленнее для тех же задач, что и С.

  • –1
    Многие матерятся на php, но вот даже тот самый хабр написан на этом языке.

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

Самое читаемое Разработка