Что произошло: 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 вырос сильнее всех.
Если еще какие-то несложные срезы будут интересны, то пишите в комментах, постараемся сделать.
Всем добра, проведите новогодние праздники с родными и друзьями и будьте всегда востребованы на рынке труда!
Комментарии (145)
ls18
27.12.2016 11:53+2Удивлен насчет PHP. Не связан ли рост с выходом PHP7?
ruFog
27.12.2016 12:16-2PHP — это лоукост и кризис, вероятно, привел к тому, что многие компании рассматривают более дешевую разработку (и разработчиков).
terryP
27.12.2016 12:45+4Не только, Java и C# это языки большого и серьезного бизнеса (правда Java ещё и язык смартфонов), они использовались в основном для заграничной разработки. С последними событиями, многие компании перевезли разработчиков (гугл и т.п.) в другие страны, в результате за границей вакансий по этим языкам стало больше, а в РФ стало меньше.
Плюс, с падением курса рубля, программистам на этих языках стало сильно выгоднее работать за границей (или удаленно), что тоже сказывается на рынке разработки. А вот PHP чаще использовался для своих разработок, чем для зарубежных, поэтому он и растет в РФ.
KotV4
27.12.2016 23:11(правда Java ещё и язык смартфонов)
А на C# мобильную разработку вывезли что ли?
Bringoff
28.12.2016 09:59Windows Phone (или Windows Mobile, вроде опять переименовали) и Xamarin даже в сумме не дают сколь бы то ни было большого процента присутствия C# на рынке мобильной разработки.
KotV4
28.12.2016 10:53+1Тем не менее, мобильная разработка на С# есть, процент присутствия на рынке — другой вопрос.
Эх… и в карму кто-то минус зарядил…Bringoff
28.12.2016 12:35Так-то мобильная разработка много на чем есть (Python, JS, C++, даже с Ruby что-то было, не считая Kotlin и прочих JVM-языков, на которых пишут под Android в той или иной степени). И вообще в этом мире бывают аномалии — от сайтов на C++ до десктопных приложений на PHP. Но в расчет их никто не берет.
Карму подровнял, но лучше о ней все же не вспоминать в комментариях :)nikolaynnov
05.01.2017 13:17+2до десктопных приложений на PHP
Встречал такое один раз. Надо было доработать одно приложение. Но там такой ад был адовый, что в итоге проще оказалось всё на C++/Qt переписать.
sayber
27.12.2016 14:54Я бы не сказал что PHP разработчики дешевые.
Хотя разброс в ценах большой.
У нас люди от 150 работают.
Компания за счет кризиса поднимается, т.к. многие участники международного booking-broker рынка отвалились и на их место частично свободно.
saboteur_kiev
27.12.2016 20:46Я думаю, что рост PHP также связан с хорошим ростом javascript/css, потому как php для них очень близок. И даже перл подрос. В тоже время как python, который не столько бэкенд, сколько универсал — упал.
KazinPro
27.12.2016 23:12Лично в нашей компании это связано с увеличением штата.
Из-за кризиса освобождает много места, где раньше были конкуренты.
AndreWin
27.12.2016 12:02+10Простите, а что, CSS – уже язык программирования?
djika
27.12.2016 12:07+2Мы отсюда частично исходные данные взяли: 15 самых популярных языков программирования по версии GitHub
bask
27.12.2016 12:16+4«Cascading Style Sheets (каскадные таблицы стилей) — формальный язык описания внешнего вида документа, написанного с использованием языка разметки.»
«язык описания» != «язык программирования»djika
27.12.2016 12:42+1Если убрать CSS, то на 18 место попадет язык ассемблера: 15 год — 13 вакансий, 16 год — 16 вакансий.
bask
27.12.2016 13:18+22То есть, CSS здесь лишь для того, чтобы ассемблер не попал в список? О_о
ZblCoder
27.12.2016 17:11+2Странно, что XML, JSON или HTML не попали, они куда чаще упоминаются в вакансиях.
terryP
27.12.2016 17:22+2XML, JSON или HTML
Вряд ли есть вакансии чисто по «языку» XML или JSON. Они упоминаются только как доп.навыки. А вот CSS/HTML или SQL вполне могут быть единственным «языком» в вакансии (верстальщик, админ баз данных и т.п.)
Darthman
27.12.2016 17:39-2SQL и CSS совершенно разного уровня вещи. И SQL это язык запросов, а не программирования, уж если на то пошло.
terryP
27.12.2016 19:39+2И SQL это язык запросов, а не программирования, уж если на то пошло.
Это вопрос терминологии. SQL — тьюринг полный, а значит он не менее ЯП, чем, скажем, Brainfuck. В вики SQL указывается как функциональный узкоспецилизированный ЯП, в принципе языки запросов и языки программирование это не исключающие друг друга множества. А всякие расширения, типа PL-SQL или Transact-SQL тем более могут считаться ЯП.
Siemargl
27.12.2016 14:19+2На Гитхаб все же преобладает Опенсорс, соответственно, все ПО компонентного типа (Delphi, Powerbuilder, частично .NET) или с коммерческими библиотеками, будет в статистике сильно страдать.
Возможно, стоит чуть шире глянуть своей статистики по вакансиям, не ограничиваясь топ-15 по гитхабу?Darthman
27.12.2016 17:41Ну вот у меня репозитории по делфи все на bitbucket и большая часть их приватная. Статистика — дело неблагодарное.
ZblCoder
27.12.2016 17:49Вся коммерция сидит на приватных системах контроля версий. Куча вакансий, где нужны знания VSS, SVN, а про гит там даже не думают. Поэтому с вами согласен. Строить статистику языков, предварительно отфильтровав их по другой статистике, уже не правильно. Также можно было предварительно отсеивать языки, по отзывам CSS сообщества.
shtifanov
27.12.2016 23:13приватно можно и на git все поднять. на одной фирме мы использовали gitlab виртуалку от bitnami, на другой — TFS + git.
в обоих случаях под .NET инфраструктуру. git настолько удобнее vss и svn, что сейчас, думаю, больше проектов переводят на него.
GennPen
27.12.2016 12:36А SQL?
AndreWin
27.12.2016 12:40-3Это язык запросов к БД. Тоже не язык программирования. И Oracle там… Это ж фирма. В общем, как-то нет доверия к этому списку языков...
djika
27.12.2016 12:50На абсолютную истину мы не претендуем, но на рынке существенное количество вакансий вроде «Разработчик Oracle» или «Программист SQL». Поэтому мы посчитали уместным включить их в наш список.
lockywolf
27.12.2016 13:35+4Вы слишком педантичны.
Для любого неспециалиста "язык программирования = формальный язык". Uml, rapide, vrml и verilog" вполне идут в ту же категорию.
genew
27.12.2016 12:37+1Так же как и Oracle
FireSecure
27.12.2016 14:23+1HR при составлении вакансии не разбирается в терминологии. Под строчкой Oracle обычно скрывается PL\sql + вагоном sql, часто с java. PL\SQL самый что ни на есть ЯП.
kellas
27.12.2016 14:46-2CSS это декларативный язык программирования.
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. ».
Bukinator
27.12.2016 12:07+5Интересно было бы увидеть привязку зарплат к языкам с детализацией по опыту.
И ещё статистику отдельный язык/технология/стэк
Yeah
27.12.2016 12:47+11А где же 1С, спросите вы?
Нет, не спросим...
kullfar
27.12.2016 13:30+2а я все же спрошу, а почему исключили? какие-то объективные причины фильтрации хотелось бы услышать
LekaOleg
27.12.2016 14:27+11C — это какая то Дич!)
kullfar
27.12.2016 16:14+4ну вот это субъективно. По мнению многих, лидер PHP, та ещё дичь
LekaOleg
27.12.2016 21:52Ну это я в шутку!)
Мой преподаватель в вузе вообще говорил что PHP язык для собак!) Но я разработчик именно на PHP (ну не только) и сейчас работаю у него в компании на должности PHP разработчика)
foobarbaz
28.12.2016 08:31Почему-то, если с этими «многими» начинать беседовать глубже, выясняется, что они понятия не имеют, что такое современный PHP.
Fesor
28.12.2016 09:08Точно так же как если бы взять разработчика на "современном PHP" и попытаться рассказать что такое "современная серверная разработка на javascript". Когда говоришь что там уже есть async/await обычно кислая мина сменяется заинтересованностью.
jacob1237
28.12.2016 11:54Можете пояснить зачем разработчику на современном PHP конструкции типа async/await? PHP сам по себе работает основываясь на совершенно другой парадигме.
Как сказал предыдущий комментатор, действительно очень много людей понятия не имеют не то что про современный PHP, но и про предметную область PHP в целом.
Чтобы было понятно, PHP — это DSL, который идеально подходит для своей ниши, но возможностей при этом дает даже больше чем нужно (расскажите, есть ли в "современном JavaScript", например, ORM уровня Doctrine2?)
Fesor
28.12.2016 12:57Можете пояснить зачем разработчику на современном 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 то может быть я стану меньше ныть.
jacob1237
28.12.2016 17:14Что бы не городить ворох колбэков и промисов. Да, есть корутины, можно строить на них (пример — 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.
Но большинство проектов писать надо уже сейчас, а не тогда когда настанет светлое будущее.
webkumo
28.12.2016 16:33-1А какой уровень этой ORM? С Hibernate сравнится? А по каким параметрам сравнивать?..
Вот интересный вы человек… как оценивать-то?
PS пренебрежительное отношение к PHP и девелоперам на нём связано с несколькими факторами:
- очень низкий порог входа… порождает дичайшее количество говнокодеров и велосипедистов
- исторически сложившееся отношение на пике популярности языка (я с ним не работал уже больше 5 лет, на тот момент он имел отвратительную архитектуру и страшное количество грабель, на которые легко наступить)
- сессионность (я не знаю, как можно работать с языком, который не имеет состояния… нет на уровне простеньких скриптов — всё понятно… но загружаться сложный движок?!..)
- по вкусу — каждый знает лично ему неприятные элементы языка
jacob1237
28.12.2016 17:38А какой уровень этой ORM? С Hibernate сравнится? А по каким параметрам сравнивать?..
Вот интересный вы человек… как оценивать-то?Вообще-то Doctrine во многом вдохновлялась именно Hibernate. Вы не знали этого?
А по каким параметрам сравнивать?
По реализованным паттернам и поддерживаемым фичам. Непонятно даже откуда такой вопрос взялся.
PS пренебрежительное отношение к PHP и девелоперам на нём связано с несколькими факторами
Пренебрежительное отношение к PHP в большинстве случаев возникает именно из-за вопиющего непонимания области его применения, а также из-за комплекса превосходства некоторых разработчиков из других областей.
И да, на PHP не пишут серьезный банковский софт, т.к. PHP для этого не создавался и в этой нише есть свои лидирующие технологии.
webkumo
30.12.2016 12:23Вообще-то Doctrine во многом вдохновлялась именно Hibernate. Вы не знали этого?
По реализованным паттернам и поддерживаемым фичам. Непонятно даже откуда такой вопрос взялся.Вопрос взялся от того, что вы, приводя пример, заявились как разбирающийся в библиотеке человек. Мне для того же — потребуется существенное время (вернуться в php, разобраться с Doctrine и т.д.). Ну и основываясь на ваших ответах, которые предполагают, что вы разбираетесь в технологии — можете сравнить Hibernate и Doctrine?
Пренебрежительное отношение к PHP в большинстве случаев возникает именно из-за вопиющего непонимания области его применения, а также из-за комплекса превосходства некоторых разработчиков из других областей.
Мой опыт общения с кодом на php и взаимодействия с проектом, реализуемым сторонней командой на php говорит иначе. Низкая квалификация и массовый говнокод даёт много-много радости при попытке заинтегрироваться (и ещё больше при переносе части функционала из php в java)...
PS это не означает, что я не видел лапшу или говнокод на java… Но сама java мешает говнокодить так же сильно, как это возможно на php.
Fesor
30.12.2016 13:44можете сравнить 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". Люди не понимают профит от этих изменений и не хотят понимать, потому что у них уже негативное восприятие связанное с тем что джависты их гнобят.
webkumo
30.12.2016 15:12Есть такая проблема. Во многом она вызвана тем, что получить какой-то результат в PHP намного проще и быстрее чем в Java.
Получаем результат -> радуемся -> эффект Даннинга Крюгера -> работаем дальше и вырабатываем привычку работать как получается -> напарываемся на проблему которую "как обычно" решить не удается и нужно развиваться и понимаем что напоролись на непреодолимую стену. А работать надо. А времени учиться нет. В итоге многие просто остаются на том уровне. Часть медленно ползет по стеночке.Ну вот это вот и приводит к
Из-за вот этого разделения на "php-ники и все остальные"
Ну а дальше — по накатанной.
Т.е. проблема изначально в более низком базовом уровне, который заставляет резко расти разрыв уровней между разработчиками в разных языках. Аналогичной проблемы нет между языками java, c#, c++ и прочими (впрочем там есть другие проблемы… но они всё же не настолько остры). Что интересно, разрыв js <-> прочие аналогичен разрыву php <-> прочие, но js имеет свою уникальную экосистему, в которой может работать только он (прочие языки вынуждены транспилироваться/компилироваться в js), а php такой сферы не имеет. За счёт этого в js-мир нередко уходят люди с практиками из других языков. Отсюда страшный кавардак в FE, но при этом там происходит существенное развитие и об этом знают "в остальном мире". Про изменения в мире php в курсе в основном программисты php. И если сам язык и инструменты начинают подтягиваться к остальным по возможностям, то вот комьюнити на текущий момент (имхо) отстаёт.
djika
27.12.2016 14:58Не исключили, добавили же под таблицей :)
kullfar
27.12.2016 16:15перефразирую вопрос.
Почему PHP в табличке, а 1С под табличкой, а не наоборот?
k102
27.12.2016 17:00+2А его можно назвать самостоятельным ЯП? Не очень с ним знаком, но он же вроде не может выполняться без самой 1С, да?
Dementor
27.12.2016 23:10Нет. Его можно применять и без платформы 1С — oscript.io
Хотя вы правы — ему нет место в одной таблице с CSS :)
MikhailMKZ
27.12.2016 23:14+1Странный аргумент. Java не может выполняться без JVM, Python не может выполняться без интерпретатора и тд.
Soffort
27.12.2016 23:14А есть ЯП, который может выполняться без интерпретатора/компилятора/среды?
Prototik
28.12.2016 01:11+1Ну… машинный код нормально так работает…
0xd34df00d
28.12.2016 08:49Не может выполняться без процессора.
Prototik
28.12.2016 17:42Так любой код не может выполнятся без процессора. Вопрос был про интерпретатор/компилятор/среду.
k102
28.12.2016 12:09-1Среда 1с как-то не тоже самое что jvm, например. Не могу точно сказать, в чем именно разница, но она имхо есть)
dadyjo
29.12.2016 17:56Платформа 1с изначально была заточена под специфические задачи. Сначала это была задача по автоматизации бухгалтерского учета. Далее она развивалась и расширялась с учетом пожеланий возникающих у ее пользователей, а функционал расширялся.
Согласитесь ведь, что сейчас мало кому придет в голову писать сайт с нуля на ассемблере или даже на си? Будут использовать набор технологий заточенных специально под это php+html+javaScript+css+mysql, скорее всего возьмут готовый шаблон и движок сайта и переделают под нужды заказчика.
Так же все обстоит и с 1с, ее используют для решения определенного круга задач.
saintbyte
27.12.2016 12:51+1А теперь предлагаю сравнить с трендами гугла. Например PHP с медленно но верно теряет популярность последние 10 лет.
terryP
27.12.2016 13:15+3Ну, одно дело мировой рынок вакансий и другое локальный рынок труда РФ. В связи с кризисом крупному бизнесу в РФ может быть не до обновления ПО, а из-за санкций компании-аутсорсеры перевозят разработку в другие страны. А вот сайты всем нужны в любое время, отсюда языки «энтерпайза» стали менее популярны. Если смотреть фриланс биржи в РФ, то по Java мало проектов, а по PHP до фига, за рубежом скорее наоборот.
marliotto
27.12.2016 23:14Интересно, почему так. Добавил в графики Java и JavaScript, они тоже падают. Разве что JS устаканился в последние годы.
https://www.google.com/trends/explore?date=all&q=%2Fm%2F060kv,%2Fm%2F07sbkfb,%2Fm%2F02p97
Может гугл изменил алгоритмы?
Fortop
29.12.2016 18:26У вас есть данные в абсолютных цифрах?
тренды штука такая… Чем больше домохозяек в интернете, тем ниже популярность специфических ай-ти технологий.
Вы это все учли, когда "предлагали"?
Siemargl
27.12.2016 13:09+2В даунсайзерах кроме древнего бейсика, функциональные языки. В кризис не до абстрактной эзотерики — работу работать надо.
А с Питона, похоже мигрировали в ПХП.
lockywolf
27.12.2016 13:54+1Странно, что ни в каком виде нет Паскаля. Я думал, ещё не все дельфисты пропали. CodeGear-то жив, вроде.
djika
27.12.2016 15:04-2Да, вы правы, Delphi стоило бы включить на 9 место.
Delphi:
2015 — 709 вакансий
2016 — 923 вакансии
Des333
28.12.2016 00:23+4А поясните, пожалуйста, что значит «стоило бы?»
Разве это не топ-20 самых востребованных языков программирования за 2016 год?
Судя по описанию это достаточно фиксированный список, который зависит только от количества вакансий. И он не должен зависеть от какой-либо вольности в трактовках.
Да, можно поспорить насчёт SQL.
Да, Вы не включили в список 1С, но хотя бы сразу написали об этом.
Но похоже, что есть ещё языки, которые также оказались в немилости и были пропущены. Если это так, то ИМХО список как-то теряет весь вложенный смысл.
Статистика бесполезна, если она неверна.djika
28.12.2016 11:33-1Суть в том, что нужно было иметь отправную точку для анализа. Мы взяли Github и TIOBE. Двадцатка строилась, как вы видите на основе количества вакансий. Стоило, потому что его не включили, хотя количество вакансий заметное.
Польза, на мой взгляд, не в конкретном месте языка, это же не «писькомерка», не соревнование, а в количестве вакансий за 15 и 16 год, чтобы оценить реальный спрос рынка на таких специалистов. Ну и в динамике первой пятерки за 5 лет, чтобы попробовать понять, как разные события влияют на спрос — это интереснее, чем место само по себе.
iandarken
28.12.2016 12:08+2А чем плох список из _всех_ языков программирования? Ну, знаете, совсем всех. И по ним уже выбрать топ-20 или сколько там, по вакансиям?
Des333
28.12.2016 21:28+2Тогда не называйте это ни «самые востребованные языки», ни «топ-20».
Неужели непонятно, что своим названием Вы утверждаете, что это языки находятся на первых N-позициях?
А в реальности может окажется, что это языки с 5 до 25 место, потому что первые 5 языков Вам не понравились.
ZblCoder
27.12.2016 15:45+1Я искал работу пару месяцев назад (Delphi + SQL), желающих нанять было очень много. Предложения были с весьма достойной заработной платой. Поэтому я тоже удивился, не увидев тут родную Delphi. Но больше всего удивился читая комментарии, что вместо CSS хотят вставить ассемблер.
Зато в этой статистике есть Delphi https://habrahabr.ru/company/kingservers/blog/307012/xxvy
28.12.2016 04:16Делфисты ещё ладно. А что делать их братьям по борланду — Билдеристам? (C++ Builder).
На делфях пишут много больших проектов (от файловых менеджеров и плееров музыки до SCADA-систем). А вот про Builder как-то непонятно. Он вроде есть и, вроде почти делфи, но где все эти люди?
Везде, где упоминается C++, обычно имеется в виду что угодно, но только не Builder.ZblCoder
28.12.2016 09:07Честно говоря, я совсем и забыл о существовании C++ Builder. У меня куча знакомых программистов которые пишут на многих языках, но что бы кто-то писал на C++ Builder, не слышал. Видать и правда, они где-то прячутся.
nikolaynnov
05.01.2017 13:31Всё таки билдеристы — это гораздо ближе к C++, чем к Дельфи, несмотря на то, что сейчас они в одной студии поставляются (RAD studio), прямо как у Майкрософт — одна ide — любой язык. А вообще в последней RAD Studio их C++ компилятор вроде как на основе CLANG'а сделан, т.е. все современные плюшки C++ поддерживает.
nikolaynnov
05.01.2017 13:38Ух ты ж жесть какая, залез на википедию, узнать не наврал ли где я, и узнал, что был ещё C# Builder.
Borland Developer Studio 2006 — единственный полноценный комплект, содержащий Delphi, C++ Builder и C# Builder.
Darthman
27.12.2016 15:48+1CodeGear тут не при чём. Делфи давно уже была у embarcadero, а сейчас уже год как собственность Idera.
Но да, делфистов еще много живых ))
mitrych
27.12.2016 14:57+3Какая-то бесполезная, по-моему, статистика. Где данные по средней предлагаемой зарплате по этим востребованным языкам? Предположу, что массово требуются программисты PHP на низкую зарплату. 1C, Obj-С, Java изначально требуют более высокого уровня, поэтому вакансий меньше и они, скорее всего, дороже.
djika
27.12.2016 14:59+2Статистика по количеству вакансий, в рамках этой задачи цели по зарплатной статистике не было. Это тоже интересно, тоже можно сделать, но тут про вакансии, то есть спрос :)
grossws
27.12.2016 16:53+10Какое это имеет отношение к
блогам^Wхабам "программирование" и "C++" (а заодно "JavaScript" и "PHP") и потоку "Разработка"? Топайте в свой "Маркетинг" или куда-нибудь ещё.
Очень хочется иметь возможность заблеклистить определенные компании, которые со своими говностатьями замусоривают ленту. Уже даже потоки ввели, чтобы этот crap был отдельно, но они всё лезут..
nolar
27.12.2016 17:05+1Рост вакансий по языкам сам по себе любопытен, но, увы, не отражает изменения баланса между языками.
Не могли бы вы посчитать не рост вакансий вообще, а либо рост/падение доли вакансий каждого языка в общей массе (например, php = было 5404/sum(2015), стало 9707/sum(2016), прирост = …), либо прирост каждго языка относительно прироста рынка в целом (например, php +79%, но все языки вместе взятые +50%, а, значит, php лишь +29%)?
alexey-lustin
27.12.2016 17:11Хитрецы блин. Когда ЗАО "1С" выпускает интеграцию с hh.ru в ЗУП 3.0 — они официально об этом пишут на сайте.
А вы так скромно под табличкой.
http://v8.1c.ru/hrm/kadrovoe_planirovanie/vakansii.htm
В абсолютных цифрах — самый востребованный язык
а то мы не знали ;-)
P.S. GoLang порадовал
YuriEmelianov
27.12.2016 23:15У меня по личномы опыту — Питон растет с каждым днем как на дрожжах, я бы ему 1-ое место дал бы по росту
KirillFormado
27.12.2016 23:21+2У меня по личному опыту — .net растет с каждым днем как на дрожжах, я бы ему 1-ое место дал бы по росту.
Каждый кулик…YuriEmelianov
28.12.2016 11:00.NET довольно востребуемый язык (к слову С# это мой основной язык). Но в последнее время с кем не говорю — переходят или уже перешли на Питон. язык прост как пареная репа, кросс-платформа и куча готовых библиотек — в этом его секрет
KirillFormado
28.12.2016 12:06А переходят с чего и для каких целей? Я как не особо из мира питона, но интересующийся ml, вижу что у него очень развита экосистема для data science и machine learning, многие вещи стандарт де-факто.
YuriEmelianov
28.12.2016 16:29Сами же и ответели, сейчас ML + DScience — все очень модно… я бы сказал на нереальном подьеме в любой фирме которая занимается мало-мальски R&D
KirillFormado
28.12.2016 12:08язык прост как пареная репа, кросс-платформа и куча готовых библиотек
И кстати, под это определение прекрасно подходит java, почему не на нее?
Gorthauer87
28.12.2016 10:34+3А в моём личном опыте все вокруг на расте пишут, и что? Его даже в топе пока нет
YuriEmelianov
28.12.2016 11:01-3Про RUST я даже и не слышал, я работаю с огромным количеством разных команд и фирм :P
Exbe
28.12.2016 00:46А можно узнать больше деталей про сбор статистики? Я замечал, что компании несколько вакансий на одну позицию открывали, но с разными заголовками и ЗП.
googol
28.12.2016 01:16+1Странно что в списках нет языка Rust. Не очень репрезентативный список imho.
gandjustas
28.12.2016 13:17+1Как эта статистика собирается?
Я пытался подобную статистику из поиска извлечь, но возникало много вопросов. Например для C# вакансии иногда не содержат C#, а содержат .NET. Часто в вакансиях более одного языка, особенно заметно на результатах поиска C++.
JavaScript вообще в каждой второй присутствует.
У вас есть способ получения "основного языка программирования" из вакансий или вы также на результаты поиска смотрите?
Lonsdaleite
28.12.2016 15:47Интересно, кому нужен SAS, на котором я пишу… Уверен, что числа будут небольшие.
unixwz
29.12.2016 21:25-1Люблю в конце года смотреть на рейтинги ЯП. Особенно радует то, что популярность Си не падает и более того возрастает.
Siemargl
29.12.2016 23:42-2Здесь немодно так писать. А если еще и напомнить, кто царь горы по скорости, еще и в карму можно отхватить =)
terryP
02.01.2017 10:49+2А если еще и напомнить, кто царь горы по скорости
По скорости работы… ассемблер. По определению быстрее него и прямых рук ничего быть не может.
По скорости разработки… точно не Си.
P.S. Си имеет свои область там где ассемблер слишком долго, а более высокоуровневый язык (даже С++) слишком медленно, но не стоит делать из него серебряную пулю или золотой молоток. Тем более что всякие Rust'ы, D, Go и т.п. переодически пытаются откусить от пирога C/C++.
Fesor
02.01.2017 15:29-1По определению быстрее него и прямых рук ничего быть не может.
тут есть нюанс такой, что помимо прямых рук нужно досканально знать нюансы платформы, на которой будет выполняться код и т.д. И ребята которые пилят GCC могут похвастаться подобными знаниями и ровностью рук. То есть GCC будет генерить вам более эффективный код нежели вы напишите руками.
Вывод, если мы возьмем подавляющее большинство разработчиков то вариант на Си будет быстрее. Остальные могут просто быть такими же быстрыми (например rust на части задач по производительности будет таким же как Си).
По скорости разработки… точно не Си.
Смотря что писать. Некоторые вещи на Си пишутся так же быстро как и много чего еще. Другой нюанс что есть куча возможностей для выстрела в ногу, которые языки вроде rust разруливают на этапе компиляции и ограничивают разработчика от подобного.
В целом же это все крайности. Идеально было бы определить языки, которые находятся в балансе между скоростью разработки, безопасности, и скоростью выполнения. Так же имеет смысл смотреть на то, как все это ложится на конкретные задачи. Если рассматривать только одну сторону медали то это чуть более чем бесполезное сравнение.
terryP
03.01.2017 10:45+2И ребята которые пилят GCC могут похвастаться подобными знаниями и ровностью рук. То есть GCC будет генерить вам более эффективный код нежели вы напишите руками. Вывод, если мы возьмем подавляющее большинство разработчиков то вариант на Си будет быстрее.
Но это может быть справедливо и дальше: те кто пилит С++/Rust/Java/C# могут похвастаться подобными знаниями и ровностью рук, а значит их компиляторы могут генерить вам более эффективный код нежели вы напишите руками сами на С (а ведь на С очень многое делается руками).
Проблема в том что на кривые руки на любом более низкоуровневом языке могут сделать код хуже чем сделает компилятор на более высокоуровневом и С тут не исключение. Как только все уходит в высокие материи вроде многопоточного программирования, работы с веб протоколами надо иметь очень прямые руки чтобы написать руками тоже что уже есть из коробки в других языках.
Поэтому вывод неверен: без прямых рук и ассемблер и С могут быть медленнее прочих языков.Siemargl
03.01.2017 18:23-1Не надо смешивать язык и библиотеки (веб, многопоточка), причем нет разницы, если библиотека является частью языка.
Go, Rust и даже скорее D(поскольку шаблоны) могут быть равными по скорости С++, но .NET и Java — только на бумаге и в простых тестах (или когда библиотечный код превалирует). Пока что
terryP
03.01.2017 20:32+2.NET и Java — только на бумаге и в простых тестах (или когда библиотечный код превалирует). Пока что
У С# и Java есть возможность компиляции в машинный код напрямую, учитывая оптимизации компиляторов и итераторов тут все неоднозначно. Может быть ситуация автоматически оптимизированный код будет более оптимальным.Siemargl
03.01.2017 23:46Это «бумажная» возможность, пока не применимая на практике.
Можем протестировать примеры, если покажете. Лично я заинтересован в C#, а в Яве из-за широкого использования рефлексии считаю подобную перспективу нереальной.terryP
04.01.2017 11:09+2а в Яве из-за широкого использования рефлексии считаю подобную перспективу нереальной
А при чем тут рефлексия и машинный код? Рефлексия это возможность управлять полями классов напрямую, другими словами запрос дай значения поля X, это не требует байт кода, только сохранения метаданных и возможность прямой ссылки на поле или метод.
Вы может быть спутали рефлексию и кодогенерацию в рантайме (динамические загрузчики классов и т.п.), но это широко используется редко и в принципе компилятор в машинный код может и динамически классы грузить. Нет тут проблем.
Можем протестировать примеры, если покажете
Да на здоровье:
1. Native Compilation Tools
2. Excelsior JET
3. JWrapper
Это «бумажная» возможность, пока не применимая на практике.
В Java это вполне коммерческие продукты за которые платят хорошие деньги.Siemargl
04.01.2017 13:32Да нет, не спутал
Эксельсиор — жутко дорогой, забыл по него
Jwrapper — это вообще не компилятор, а упаковщик исполнимого байткода вместе с JRE,
читаю про JServer Accelerator — так там вообще мрак и Оракл 8й версии
Про NET нет вариантов (точнее еще NET Native не готов)
Вы это пробовали лично?terryP
04.01.2017 13:51+1Да нет, не спутал
Рефлексия в Java не меняет байт код, она меняет объекты классов. Объекты классов лежат в памяти и представляют обычные структуры данных. В терминах Си она сохраняет указатели на поля и методы объектов классов и позволяет обратиться в полю или методу по указателю. Ничего такого что нельзя было сделать на чистом С++.
По вашей ссылки на вики видно что рефлексия прекрасно существует и в компилированных языках.
Вы это пробовали лично?
Был опыт использования Эксельсиор'аSiemargl
04.01.2017 15:34Не так все просто с рефлексией, RTTI недостаточно.
Тот же сайт Эксельсиора честно пишет — что с класслоадером используется обычная JIT-технология.
Примерно то же пишет и Микрософт с ограничениями Net NativeterryP
04.01.2017 16:09+2Тот же сайт Эксельсиора честно пишет — что с класслоадером используется обычная JIT-технология.
Ещё раз какое отношение ClassLoader имеет к Reflection API? Это никак не связанные в Java вещи. ClassLoader служит для загрузки новых классов, Reflection для изменения объектов существующих классов. Они вообще не связаны. Кастомные ClassLoader в Java используются редко, так это крайне небезопасно и вообще сильный хак.Siemargl
04.01.2017 16:32Рефлексия это динамическое изменение программы. Класслоадер — просто частный случай — способ реализации одной из сторон рефлексии.
terryP
04.01.2017 16:52+2Это вопрос терминологии, но важен тот факт что рефлексия в Java часто используется для получения данных об объектах, но редко для изменения кода. Более того некоторые из реализаций Java (например, Java в Android) вообще не имеют возможности изменения байт кода. Поэтому рефлексия в Java не мешает реализации машинной компиляции.
Fesor
03.01.2017 21:51Rust в целом не особо уступает C. Там конечно есть свои особенности и тикеты в трекере с пометкой slow, но они постепенно закрываются.
но .NET и Java — только на бумаге и в простых тестах (или когда библиотечный код превалирует). Пока что
Опять же смотря что брать и как мерять. JIT оптимизирует только горячий код, и делает это в случае с JVM весьма эффективно. Да, есть нюансы, но JVM в последних версиях вроде как умеет и циклы разворачивать сама и векторизацию вычислений. Так что… Все относительно и зависит от задачи. Ну и опять же, мы можем реализовать на Си те 1% кода которые являются батлнеком на худой конец.
Siemargl
03.01.2017 23:47В JVM великолепный оптимизатор.
Единственное, что он не может — это разумно использовать память.
И тут то самое интересный корень проблем.
nikolaynnov
05.01.2017 14:46По определению быстрее него и прямых рук ничего быть не может.
тут есть нюанс такой, что помимо прямых рук нужно досканально знать нюансы платформы, на которой будет выполняться код и т.д. И ребята которые пилят 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.Siemargl
05.01.2017 15:47Ну так дело то не в том, что Си быстрее или медленнее в данном случае =)
А сравниваются две ассемблерные реализации — поскольку все Сишные (да и не только Сишные) интринсики (intrinsics) написаны на ассемблере.
Просто не надо велосипедить, надо брать вылизанные библиотеки.nikolaynnov
06.01.2017 00:56Ну как бы я пытался 2 мысли донести, про ассемблер ничего плохого не говорил:
1) [очевидная истина, можно ассемблершик и сишник заменить почти любыми другими] если у ассемблерщика кривые руки, то он в большей части случае напишет хуже, чем сишник с прямыми руками.
2) [поддерживал предыдущего комментатора, про необходимость досконально знать нюансов платформы, под которую надо писать код ] даже если у ассемблерщика руки вроде как прямые, но он застрял в 90-х (с таблицами сколько тактов выполняются mmx инструкции на pentium 2), то такой тоже ничего хорошего не напишет в современных реалиях. Кстати ещё один случай вспомнился, как мне ассемблерщик доказывал что никак его код не мог замедлить программу. Так ему не понравился сгенеренный компилятор код и он решил написать свою реализацию на ассемблере. Ему тогда не понравился div, и он цитировал что-то вроде «Так, для 386-процессоров выполнение деления на двойное слово требует 38 тактов процессора, на слово — 22 такта, на байт — 14 тактов.». Пришлось ему найти спеку на современные интеловские процы, в которых div занимает 1 такт. Да и вообще, сейчас с конвейерами в процессорах уже никогда нельзя быть точно уверенным сколько тактов займёт та или иная ассемблерная команда, только прицениться на лучший и худший случаи. Поэтому у меня и вызывают уважение парни из ffmpeg'а или наши интеловцы из Нижнего, которые ipp пишут.
0xd34df00d
06.01.2017 18:40а более высокоуровневый язык (даже С++) слишком медленно
C++ сам по себе не может быть медленнее для тех же задач, что и С.
Optik
Спасибо, что поиск теперь работает лучше чем год назад, когда на запрос scala выдавалось еще всё со словом scalable. А вакансий субъективно стало наоборот больше.