Comments 85
Как менялись зарплаты и популярность языков программирования за последние 2 го
Немного о себе. Я программист с 1974 года.
На мой взгляд вы взяли не очень удачный период. Как менялась зарплата? В лучшем случае никак (я сужу по малому и среднему бизнесу ).
Теперь о популярности языков. Естественно, основным моим языком был и есть Си. Но вот (как раз в тот промежуток времени, который вы рассматриваете) мне потребовалось написать графическую утилиту. Работа была рутинная и так не хотелось ее делать на Си с Qt. На свое счастье я вспомнил про Tcl/Tk, к которому не обращался с 1998 года. И я понял как я много потерял за эти годы.
Сегодня он для меня стал вторым по значимости языком. Чего только на нем н пишу: УЦ, утилиты управления токенами PKCS#11 и т.д. и т.п.
Видим одновременный заметный рост зарплат
Вот тут я не могу согласиться с вами или мне просто не везет! Может другие языки использовать?
А Вы попробуйте изучить тот же Go, хуже не будет :)
Аналогичное встречное предложение :)
Я смотрел Go.
Это как? Парадигма сменилась? Новые знания перестали в голове умещаться? Или Вы про смену работы и на Go теперь грустно писать?
Ну лично мне стало плохо от того, что язык настолько популярен, а я не могу выразить в нем привычные концепции кроме как портянкой кода в полэкрана и через отключение проверки типов (привет. interface {})
Делитесь примерами, обсудим; может быть просто хотелось писать код не в парадигме языка.
Ну исключения я и сам не люблю, АДТ наше все. А вот генерики — да. Когда мне говорят, что генерики это только для библиотечного кода, который пишется один раз в жизни и в реальном коде никогда не нужен, мне становится интересно, чем занимаются люди, которым не приходится решать задач, требующих обобщения.
Ну, я взял рандомный микросервис, и запустил две регулярки:
Search "(public|private).+\(" (671 hits in 159 files)
Search "(public|private).+<T.+?\(" (43 hits in 17 files)Получается порядка 10% объявленных методов это генерики.
Если искать типы то расклад такой:
Search "(class|interface)\s+[^<]+\b" (232 hits in 228 files)
Search "(class|interface)\s+\w+<" (16 hits in 16 files)В насквозь прикладном микросервисе опять же порядка 10% генерик типов (только объявленных собственных).
Сколько используется чужих генериков (из кастомных библиотек, к примеру) не берусь считать, но думаю половина кода спокойно выйдет.
Ну буквально в среду у меня была задача батчить разные действия с монгой, потому что она не справлялась с нагрузкой.
В итоге появился класс вида
public class ActionBatcher<T>
{
private readonly Action<IReadOnlyList<T>> action;
private List<T> batch;
public ActionBatcher(Action<IReadOnlyList<T>> action)
{
this.action = action;
}
public bool IsRunning { get; private set; }
public void RunOrBatch(T item) { ... }
public void RunNextBatch() { ... }
...
}Простой, понятный класс, который собирает некие объекты в батч, и выполняет заданные действия над тем, что успел собрать с момента последнего запуска. Ни разу не библиотечный код из башни слоновой кости, обычный тип решающий конкретную практическую задачу.
- Класс используется с десятком различных T, поэтому копипастить одну и ту же реализацию очень не хочется
- Использовать
interface{}не вариант, потому что аналогом был быdynamicсо всеми соответствующими минусами отключенной типизации.
А если все же рассматривать случаи без дженериков и обобщенных классов? А то получается давите в известное слабое место, а суждение о возможностях языка делаете более общее.
P.S. Не хочу расстраивать, но класс спроектирован неважно. С точки зрения пользователя непонятно, зачем там публичный IsRunning, ведь для многопоточной среды код не годится, а в однопоточной по очевидной причине он не нужен. Так же странно выглядит разный объем батча, необходимость явно вызывать обработку, да и в целом непонятно, почему проблемы с монгой пришлось решать так.
А если все же рассматривать случаи без дженериков и обобщенных классов? А то получается давите в известное слабое место, а суждение о возможностях языка делаете более общее.
Я хотел как раз показать, что обобщенное и генерик-программирование занимает очень большой процент от основного пласта задач. А учитывая генерик-код библиотек которые мы используем процент обобщенного кода думаю за 90% переходит.
С точки зрения пользователя непонятно, зачем там публичный IsRunning
В некоторых сценариях нужно понимать, идет ли сейчас выполнение какой-то операции или нет. В основном для логгирования.
ведь для многопоточной среды код не годится
Код и не предполагается для работы в многопотоке. Точнее, вопрос многопоточности на себя берет акка, а с точки зрения пользовательского кода он синхронный
а в однопоточной по очевидной причине он не нужен
А как вам понять, идет ли сейча выполнение кода? Для работы кода это. конечно, не нужно, а вот для логгирования пригодится. Возможно можно было бы выставлять публичное ридонли свойство элементов которые должны будут попасть в обработку, но в тех сценариях что были в коде можно было обойтись булкой.
Так же странно выглядит разный объем батча, необходимость явно вызывать обработку, да и в целом непонятно, почему проблемы с монгой пришлось решать так.
Просто снижение нагрузки на БД. За счет этого батчера получается не выполнять операции записи, которые все равно будут выкинуты. В частности, таким образом батчатся разные версии одной сущности, в итоге в БД улетает только один запрос на изменение, а не 100.
Ну и да, вопрос проектирования довольно спорный, вы ведь не знаете моих ограничений/требований/..., не говоря про ограничение по времени на выполнение задачи, поэтому предлагаю исходить из того, что задача "нужно батчить подобным образом задачи" есть. Как её решать я не ограничиваю вас никак, я пришел к такой абстракции, покажите, какую абстракцию мне предлагает го и как с ней работать.
А как метод IsRunning вернёт результат, если, собственно, этот поток сейчас "running" и находится внутри переданного action?..
Видимо, это классическая проблема с именованием :) IsRunning по сути показывает некоторую другую метрику, которая ресеттится через попытку запустить следующий батч, если больше нет работы. Возможно, действительно лучше будет немного порефакторить и убрать это поле.
В Ну даже если. уберите лишнее, основной поинт остается: вот мне в максимально прикладном коде понадобилась такая структура данных. Как мне обойтись средствами языка, который не позволяет выражать генерики и не потерять в читаемости/типобезопасности?
Я как-то случайно в данном обсуждении затесался в ярые защитники Go. На самом деле я скорее считаю, что каждому инструменту свое применение, и Go в том числе. Где-то он хорош, а где-то нет. Но тем не менее, прямые и безусловные категоричные суждения язык явно не заслуживает. Ибо один бинарник без рантайма и зависимостей это не "наоборот". Можно использовать докер образ scratch и иметь контейнер весом в пару менабайт это не "наоборот". Кросс-компиляция под любую платформу на любой платформе это не "наоборот". Запуск сопрограмм одним ключевым словом это не "наоборот". Решение проблемы 10к запросов в секунду коробочным http-сервером это не "наоборот".
Как мне кажется, "не очень мне интересно" не является достаточным основанием высказывать безусловные суждения о профнепригодности или технологической ущербности языка. В режиме "ой всё" напомню цитату "есть языки, которые все ругают, а есть те, на которых никто пишет". На Go пишут много и повсеместно.
Что подразумевалось под рантаймом?
А как замена C/Python для простых командных утилиток — пойдёт.
Тот же C тоже бывает разный. Есть студенты, которые пилят говнокод для Ардуино, а есть люди, решающие задачи, которые по большому счёту ни на чём кроме С и не решить, использующие API Linux, которые нигде в литературе не описаны, поэтому им приходится изучать патчи ядра, lwn и списки рассылки.
Обобщённое программирование в основном требуется для своего рода "библиотечного" функционала, который подразумевает переиспользование. Я прекрасно понимаю, как без него порой плохо — например, в текущем проекте есть один core-класс, на котором строятся временные ряды, без которого было бы совсем грустно, и в Go пришлось бы генерировать код. Но если отбросить эту проблему, неужели плюсы не перевесили?
Обобщённое программирование (или динамическая типизация, которая его по сути подразумевает) требуется для написания хорошего чистого кода, где намерение выражено явно, нет дублирования, код короткий насколько это возможно, написан на должном уровне абстракции и т.д.
Оу, даже так. Тогда, наверное, и нечего противопоставить в контексте преимуществ Go, если безопасность типов и в разы меньшая вероятность проблем от их несоответствия в рантайме для Вас меньше значит, чем абстракции дженериков.
"Недостаточно выразительна" трудно интерпретировать однозначно, поэтому если вы поясните мысль, я буду признателен.
Мне ее возможностей в целом достаточно, если опять же не возвращаться к дженерикам.
Могу привести аналогию. "Мне возможностей С++ целом достаточно, если опять же не возвращаться к безопасности памяти". В этом ведь ключевая проблема, и это не "лишь" один нюанс при куче плюсов, это штука которая перечеркивает любые преимущества в почти любых задачах.
А, это та самая библиотека с 0 Stars, Issues и Pull requests...
> контейнер, в котором тип значения определяется значением ключа, а… И т.д.
если этой «библиотекой» кроме вас пользуется 0 человек. Может быть это было неплохое умственное упражнение, и Вы им гордитесь, но его упоминание в контексте системы типов не добавляет веса словам.
К тому же, опять же по моему мнению, не очень справедливо козырять всякими хаскелями, когда сравниваются, в общем-то мейнстрим языки. Давайте более приземлённые кейсы и языки рассматривать, на которых люди пишут за деньги, а не упражняются в выделывании хитрых конструкций.
А когда понимаешь, что никак не получится создать функцию, которая бы принимала на вход любые структуры, имеющие определённый набор полей, то становится действительно горько.
Использовать interface{} и приведение типов? Ага, и править бесконечные switch-statements по всему коду при добавлении нового типа? Это классический антипаттерн «как не надо делать полиморфизм», который дядюшка Боб приводит в каждой второй лекции.
Использовать interface{} и рефлексию? Это всё распространится как рак по всему коду, также «безопасно» как указатели в Си и ужасающе неудобно.
И вообще: interface{} — это та же динамическая типизация, только хуже, потому что неудобно и то, что Python делает автоматически, придётся писать вручную. Его применение считается в Go антипаттерном и неспроста.
Есть ещё один вариант, по которому большинство и идёт: копипастить код как обезьяна. Нет, спасибо.
Я бы написал рутинную графическую утилиту на QML. Tcl я очень уважаю, но пишу на нем главным образом скрипты автоматизации, Tk практически не пользуюсь. Но это вопрос вкуса.
Просто в качестве ироничного наблюдения за этим графиком:
1) Чем хардкорнее язык и сложнее на нём писать — тем меньше на нём разработчиков.
А по экстремумам:
2) Этим же и сказывается падение популярности PHP, т.к. за последние 4 года он очень круто вырос в сторону строгой типизации (стал более хардкорным), качества кода и в целом.
3) Этим же обуславливается повышение популярности JS, там дофига всякого сахара добавили (стал менее хардкорным) за последние 4 года.
Естественно, эти выводы притянуты "за уши" и кое-где не соответствуют действительности, но в целом ведь похоже вырисовывается? =)
А никто и не говорит о том, что везде всё точно. Тот же Go будет попроще плюсов.
не совсем понятно, почему вы слабую типизацию к хардкору относите. Поиск и отладка некоторых багов в программах на слабо типизированных языках может быть еще большим хардкором :)
И динамическую в т.ч. И не к усложнению, а наоборот, к упрощению отношу.
На С++ писать сложнее, чем на хаскеле, но разработчиков на первом больше.
зарплаты будем по полугодиям, в каждом из которых мы собираем более чем по 7 тысяч зарплат
По данным википедии у вас в Яндексе 8 с хвостиком тысяч сотрудников. Интересно как часто происходил пересмотр зарплат у ваших сотрудников за последние 2 года и как влияют на решение такие вот медианые цифры, собираемые на Моем Круге?
Но вы задали очень интересный вопрос, нужно провести опрос среди компаний и узнать, насколько относительно молодой еще сервис зарплат влияет на зарплатную политику.
Я знаю, что некоторые эйчары рекомендуют держать зарплаты сотрудников в пределах 20% диапазона относительно средней. Если же этого не получается, то у компании есть еще много вариантов компенсировать недостаток зарплаты, например: делать офигенный продукт, создавать комфортные условия труда, внедрять современные технологии, заниматься профессиональным развитием сотрудников, выстраивать гоамотный менеджмент и т.д.
Это реально статья от математика, а не от того, кто в теме.
На примере того же PHP, есть по сути две части выдачи вакансий по теме, одна часть — это серьезная разработка, вторая — это WordPress и прочая нечисть, в которой тоже употребляется это слово. Вот без сравнения этих частей информация вообще не даёт никакой информации.
По редким языкам с большой оплатой, без анализа вакансий не понятно, это перспективные направления или просто люди когда-то влезли в фигню и теперь готовы сильно переплачивать, чтобы не переписывать все с нуля.
Требования по стажу тоже не учитываются.
И ещё много вопросов к этим цифрам, в таком виде анализ не имеет никакого смысла.
P.S. Посмотрите, как делают статистику на DOU.ua по языкам и по зарплатам.
p.s. А дайте ссылочку на то, как делают статистику DOU. Мы их знаем и уважаем, но делаем примерно также, а где-то даже чуть лучше, как мне кажется. И вы же видели другие наши исследования зарплат, что мы регулярно выпускаем на Хабре?
С другой стороны, динамика явно стабильно положительная. Через годик это уже будет вполне себе маленький, но рынок труда. Например по Elixir, который есть в статистике поста, HH выдаёт всего 43 результата. Что, по вашему, вероятнее вырастет — раст или эликсир?
17.06 — 35
26.06 — 37
02.07 — 40
04.07 — 41
05.07 — 42
10.07 — 46
15.07 — 45
23.07 — 47
26.07 — 49
30.07 — 50
50.08 — 49
12.08 — 50
14.08 — 51
16.08 — 57
21.08 — 53
23.08 — 51
Есть мнение, что ваша статистика немного искажена отпусками HR'ов. В начале лета с работой всегда хуже дела обстоят.
А я вот задумался на том что охранник сидит и получают 20К, это же весь день смотрят монитор проверяет камеры. Почему зарплата программиста в несколько раз больше чем зарплата у охранника с чем это связано я работал программистом 2 недели у меня сильно заболела спина жопа глаза. А работа охранника такая же. Сложность разная но со временем опыт наростает, и сложности и нет.
Скажите, что я делаю не так?
А вообще еще кто-нибудь сейчас занимается программированием и выбором инструмента под решение задачи или в этой индустрии теперь все тупо лишь мечтают о зарплатах? :D
Это корпоративная система, фриланс, просто работа в нескольких проектах? )
Ну и уровень должности, если не сложно. (разработчик? ведущий? свой проект? свой отдел? архитектор? начальник всея айти?)
> А кто говорит, что вы что-то делаете не так?
Вы иронию понимаете? ;)
> Просто у вас необычный случай… и ваша зарплата за этот стек…
Необычный случай? Зарплата за Стек? Что вы несете?
Классическое найтивное программирование вдруг стало чем-то необычным?
А платят теперь за понятие «стек технологий» (так любимое эффективными менеджерами) а не за результат, здравый смысл и возможность писать быстрые программы без каких-либо ненужных прослоек?
Давайте я объяснюсь.
Я уже писал как-то в другой теме, что вот включаю я свой персональный компьютер и не вижу там ни одной хоть сколько бы серьезной и нужной мне программы, написанной на javascript-е. И уж тем более ни одной на Питоне. А ведь последний чуть ли не в лидерах должен быть по количеству шума вокруг него в последние годы.
Но я ничего не вижу на десктопе и из лидеров данного конкретного списка. За исключением разве что Objective-C (но я не вижу и Objective-C, поскольку в моей области деятельности Маки нафиг никому не нужны).
Да у меня даже и на C#-то на десктопе днем с огнем ничего не сыщешь (кроме разве что каких-то мелочей от самой MS). Хотя, казалось бы, это-то должно бы давно уже появиться.
Все графические редакторы, все инженерные и математические пакеты, весь 3D, все нужные мне офисы и бухгалтерии, все системные утилиты и прочие интрументы для работы, все это либо C++, либо в том числе и Delphi (Delphi в моем случае это AIMP, утилиты Auslogics и хелпмэйкер HelpNDoc, пару хороших утилит для Баз-данных включая DBWorkbench, сборщик FinalBuilder и шикарный но дорогой автотестер TestComplete ). И просто поверьте, что я не выбираю программное обеспечение по принципу на чем это сделано.
И только не нужно мне рассказывать, что это мол де десктоп, а вот у нас мол в корпоративе все крутится на серверном скриптике «A» под библиотечкой «B» с прикрученными справа и слева пакетами «C» и «D», а визуализируется на HTML страничках под нехилым набором из новомодненьких библиотек E, F, G (набор которых чуть ли не каждые пару-тройку лет меняются).
И изначально все это было задумано вашими «эффективными менеджерами», чтобы ускорить и упростить.
Только на деле чаще всего выходит, что на создание и отладку всего этого времени уходит не меньше, а то и больше, чем на написание быстрого десктопа и серверной части сразу под конкретные платформы (естественно, кроме самих серверов и баз данных). А хуже то, что постоянная изменчивость и нестабильность вышеперечисленных «стеков», помноженная на нестройность и не строгость скриптовых технологий, еще раз помноженная на слабую компетентность непрофильных специалистов и четвертый раз помноженное на естественные скриптовые тормоза никак в результате не приводит к заветному для «эффективных менеджеров» удешевлению и упрощению.
Да и в результате чаще всего мы видим лишь очередную эмуляцию десктопа в Браузере, поскольку все html красивоти для серьезной работы как бы нафиг не нужны. Ну и не факт, что это вообще будет работать через пару лет при смене браузера и поколения скриптового движка.
При этом я вовсе не умаляю существенную значимость того же javascript-а в сайтостроительстве.
Хотя по размерам кода современных сайтов IMHO на таком изначальном убожестве это писать уже опасно. Недаром и появляются обертки типа typescript-ов
> При итоговом выборе вступают еще и другие критерии, как, например, количество людей на рынке труда могущих, и главное желающих с ним работать, чтобы потом было кому поддерживать и развивать это всё.
Ну вы же, думаю, не надеетесь, что что-либо из вышеперечисленных мной серьезных пакетов будет вдруг непонятно зачем переписано на какую-нибудь Скалу или Го лишь мимолетной моды ради?
Или тем более на скриптовые тормоза?
А главное зачем?! Чтобы нанять якобы дешевых спецов? См.выше. Да и по факту спецы эти уже не дешевы.
А теперь давайте более предметно и прагматично.
Вот нужны десктопные морды с небольшими мобильными довесками.
В силу задач (управление промышленными контроллерами) на десктопе желательно иметь возможность быстро спускаться до низкоуровневого программирования и время отклика должно быть минимален по возможности. Т.е. желателен быстрый найтив.
C# и вообще менеджет подход не желателен (к тому же часть все равно придется писать на найтиве).
Ну, например, можно и на С++Qt, благо опыт есть.
Но оказывается, что и современный Дельфи совсем не плох.
Интерфейсная часть накидывается элементарно и относительно быстро. А при использовании FMX теперь можно это замутить хоть даже и под Линукс. А вся подноготная часть пишется одинаково просто хоть на прикладном уровне, хоть на уровне прямого доступа к памяти и даже ассемблера и с почти бесшовным склеиванием с СОМ и низкоуровневым API на любой поддерживаемой платформе. При этом вероятность выстрелить себе в ногу при написании рутинной части все же существенно меньше, чем на C++.
Специалистов на просторах СНГ полно, да и за пределами есть. И это уже чаще именно специалисты, а не ничего не знающие пока толком школьники, которые лишь мечтают вызубрить (именно вызубрить) какую-то очередную новомодную фенечку ради заветной большой зарплаты.
Но только даже на моих глазах таких фенечек с 90-х уже куча промелькнула и пропала в никуда.
И знаете, я бы все понял, если бы в этих списках новомодных и хорошо-оплачиваемых языков, появлялись бы такие вещи как язык «D». И не только появлялись, но и выходили бы хорошие IDE, а сторонние фирмы наперебой клепали бы инфраструктуру и компоненты для этого.
Но вместо этого лишь куча таких же как и «D» многообещающих, но бесплодных выстрелов.
Ну или если бы C# на найтив перевели с возможностью прямого доступа к пямяти и ее очистки по желанию и т.п.( а ведь грозились когда-то).
А вместо этого MS лишь мечутся как Г в проруби и регулярно кидают своих адептов.
И вот на этом фоне Дельфи или даже Лазарь на найтиве выглядят весьма даже неплохо и развиваются вполне предсказуемо и стабильно. Не говоря уже о конечном результате в виде единственного запускаемого файла, который стабильно, быстро и совершенно не прожорливо пашет потом годами и ему как и Си-шному найтиву очень долго потом плевать и на смену операционок, и от смен прослоек он тоже не зависит.
Поэтому, если я могу к счастью выбрать сам, не опираясь на мнения «эффективных менеджеров» (ака недоучек из экономических колледжей) и не на мнение тинейджеров без профильного образования, то выходит, что и Дельфи живее всех живых, да еще и мобильные довески делать позволяет опираясь практически ровно на тот же код.
А платят мне и напарнику за конечный результат, а не зарплату. Поэтому, и сумма в среднем большая выходит.
в этой индустрии теперь все тупо лишь мечтают о зарплатах?
Ну, логично, что работа по найму — это в первую очередь, о зарплате сейчас, а во вторую очередь, о зарплате, если текущее место перестанет существовать. Что тут не так?
Не так здесь то, что во времена моей учебы программазмом и схемотехникой в основном занимались те, кому это было реально интересно. Поэтому, на выходе из ВУЗов как правило уже получались специалисты весьма высокого уровня и хорошо знающие основы. А шелуха типа зубрежки языков или переключение между ними в зависимости от задачи была как бы немного вторична.
А карьеристы за зарплатой тогда шли в Финэк или на юридические факультеты. И приблизительно так же обсуждали, что бы им по-быстрому и попроще поучить, чтобы в блатную конторку на хорошую зарплату пристроиться.
А теперь все перевернулось наоборот :)
Как менялись зарплаты и популярность языков программирования за последние 2 года