Как стать автором
Обновить

Самые редкие и самые дорогие языки программирования. Часть II

Время на прочтение 5 мин
Количество просмотров 52K
Всего голосов 37: ↑28 и ↓9 +19
Комментарии 94

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

Среднюю российскую зарплату не очень выводить к примеру в Москве зарплата будет топовой, в Белгороде или в других городах меньше. Удаленную работу ни кто не отменял, но не всем будет нравится так работать. По этому как правило в регионах зарплата ниже, где то и на порядок.
Ну давайте среднюю по Москве, чтобы сравнить между собой и с другими.
Протестую, это шовинизм,
в списке нет редких языков графического программирования.
Например язык «G» aka часть среды разработки Labview.
ХХ показывает 26 активных вакансий в РФ

А еще Tk, который встроен и в Tcl, и в Perl, и в Python и т.д.

А еще Tk

Это не совсем то. Tk — графическая библиотека, как GTK или Qt. А G — графический язык программирования, где вместо кода блоки, соединяемые стрелочками, и писать программы можно мышкой
Мы делали анализ на основе комментариев к первой статье, если бы пользователи хабра запросили сделать анализ о языке «G», мы с удовольствием бы это сделали =)
Правильнее было бы назвать не редкие, а устаревшие языки.
VHDL с Verilog пока ещё особо нечем заменить, новые ещё не подросли. А tcl — составная часть стека разработки под железо, так что тоже пригодится.
А tcl — составная часть стека разработки под железо, так что тоже пригодится.

Какое вы железо имеете ввиду?
FPGA. У Xilinx вся среда Vivado внутри использует tcl и многие вещи, недоступные из GUI можно сделать только скриптами. А многие вещи удобно загонять в скрипты и выполнять потом пачками, вместо ручного режима в GUI. Наконец свежие фичи также обкатываются пользователями сначала в tcl, а потом уже выносятся в GUI (например так было с частичной реконфигурацией, её сначала можно было пощупать только скриптами, а в более поздней версии среды она появилась в GUI). А если проект из Vivado надо загнать под git, то тут тоже придется ковырять tcl…
Аналогично в квартусе от интела широко используется tcl.
НЛО прилетело и опубликовало эту надпись здесь
Мы похоже уходим в оффтоп, так что заранее прошу меня извинить). Прошить Spartan без tcl можно Impact-ом — GUI тулза от Xilinx. В целом прошивка происходит через jtag и потолок там где-то в районе 10 Мбайт/с, это аппаратное ограничение. Насчет сишных либ для прошивки, я не проверял, знаю, что формат и протокол битстрима держится в секрете, и также что его не так давно разреверсили, так что либы наверно можно поискать. Что касается взаимодействия с ПЛИС после прошивки и передачи в неё больших объемов данных, то тут большой простор для творчества: данные можно передавать например через интерфейсы Fast Ethernet/Gigabit Ethernet, PCI-express и прочие. Для них наверняка можно найти и сишные либы, ну и фишка акселераторов на ПЛИС как раз в использовании таких стандартных и быстрых интерфейсов. Spartan 6 уже староваты, в 7 семействе гораздо веселее всё с интерфейсами. Далее, если вам всё же надо быстрее сконфигурировать ПЛИС, чем обычным jtag, то тут можно попробовать частичную динамическую реконфигурацию в паре с одним из быстрых интерфейсов (Gig Ethernet, PCI-express): прошивку загружаете через быстрый интерфейс, а зашивается она через внутренний конфигурационный интерфейс.
А у jtag программатора обычного не 3 МГц, частота максимальная, т.е. 3Мбод/с?
Там вроде какие-то сторонние решения до 30 Мбит/с, но никак не десяток МБайт/с…
Да, вы правы. Порядки помнил очень приблизительно.
НЛО прилетело и опубликовало эту надпись здесь
Я может не понял, а виртуальный рабочий стол не поможет?
Затык прям в чипскопе и даже без клиент-серверов прямо на машине чипскоп тоже будет тормозить?
НЛО прилетело и опубликовало эту надпись здесь
Uart какой-нибудь может попробовать? Если это sp601 или 605 отладочные платы, там вроде бы есть uart-usb.
Прикольные вещи вы там вытворяете).
Мы наверно не поняли друг друга, я имел ввиду, что сам файлик битстрима (.bit или .bin), соответствие его содержимого элементам в ПЛИС, порядку их инициализации и т.д. держится в секрете. Битстрим чем-то напоминает ДНК, тоже набор инструкций и содержимого для инициализации, рецепт, поэтому употребил слово «протокол».
Про chipscope я не особо в теме, но вроде как это средство отладки, местами графической, с совсем малым количеством ресурсов, т.е. им бы глядеть пару самых подозрительных сигналов, не работающих в железе, на тысяче-другой сэмплов. Вам точно надо именно через него грузить данные в ПЛИС? Обычный uart не сойдет? Хотя скорости, конечно, на нем тоже не ахти.
НЛО прилетело и опубликовало эту надпись здесь

Не важно, считают ли Cobol устаревшим или нет, он продолжает работать и обрабатывать существенно больше половины банковских транзаций, а значит, нужны специалисты способные поддерживать продукты на нём написанные.

он продолжает работать и обрабатывать существенно больше половины банковских транзаций

Я думаю, сейчас это преувеличение. Где-то ещё работает, конечно, но в целом банки при всей своей инертности регулярно обновляют железо, и постепенно избавляются от самого древнего легаси-софта.

Ну, например, в Японии банк Mizuho по сей день плотно на коболе сидит. С тех пор как в 2011 случился коллапс системы, начали шевелиться, вроде к 2020-2022 планируют полностью закончить переход на что-то поновее.

И много ли таких ещё осталось среди всех банков?

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

На Java 1.3? :)
Я что-то сомневаюсь. Я слышал этот тезис в 1990-х, но подозреваю что все таки заметное количество банковского софта переписано на Java, Go или чем-то еще — появились новые стандарты, протоколы.

Можно произвести опрос программистов из Альфы, Тинкькофф, Рокетбанка — сколько у них там работает Cobol специалистов на сопровождении. Я думаю 0.
Можно произвести опрос программистов из Альфы, Тинкькофф, Рокетбанка

Я думаю, надо спрашивать программистов из Bank of America и JP Morgan.
Статья вроде на основе анализа hh.ru и написана в контексте России.
Да, но исходный тезис о Коболе таких условий не содержал. То, что у «новых» банков, типа Рокета, возможно нет Кобола — это неудивительно. Вопрос в том, переписывали ли свои системы те, кто с Коболом начинал. И если переписывали — то в каком объеме и насколько глубоко.
Фактически Рокет — не банк, это некий прокси-сервис который изначально был сам по себе и имел договор с банком в котором держал счета клиентов а потом его выкупил банк и уже снова успел продать другому… Ну де юре тоже банку. Сервис, впрочем, шикарный, но сам по себе он банком никогда не был.
Когда Cobol был популярен, этих банков еще не было, так что не удивительно.
Мы согласны с Вами, по нашим данным, большинство банков используют Java.
Про Verilog — просто в России почти не проектируют микросхемы, вот и все. Он не устарел, все процессоры и видокарты на нем написаны, да и наш Elbrus на нем же.

Скажите, а вы компаниям ищите программистов на заданном языке?


Как вы думаете, что займёт больше времени для хорошего программиста — выучить средней руки язык программирования (php/perl) вместе с его lore и staple libs, или настроить себе рабочую машину, завести аккаунт, почту, vpn, выучить расположение кофе-машины, туалета, метод выезда с парковки, адреса местного багтрекера, ci-сервера, git-сервера, вики, стейджинга, имена тестовых серверов и процедуру получения доступа к ним?


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

Что такое «выучить язык»?
Знаю программистов на С++, которые имеют опыт +15 лет и при этом до сих пор умудряются стрелять себе в ноги.

Программистов на С и С++ не существует.


Доказательство:


  • программа с undefined behavior не является программой на C и/или С++
  • все более-менее крупные программы, которые начинали писать на С/С++ содержат баги с UB, т.е. они не являются больше программами на С/С++
  • Люди пишут на чём-то, что не является С/С++, т.е. не являются программистами на С/С++.

PS Как вы думаете, за какое время человек, который писал на Rust/Haskell начнёт терпимо пытаться писать на С?

Как раз после некоторого опыта с Rust уровень кода выдаваемого на C резко повышается, поскольку компилятор Rust тренирует программиста как собачку павлова писать программы без UB.

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


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

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

Не соглашусь. К примеру:

адреса местного багтрекера, ci-сервера, git-сервера, вики, стейджинга, имена тестовых серверов и процедуру получения доступа к ним?

Закладки / скрипты — и все дела (я не представляю как и зачем держать в памяти все такие вещи). Получение доступа должно быть частью onboarding (как это по-русски?) в нормальной компании, равно как и почта, VPN и прочие подобные вещи. Настроить рабочую машину для работы в хорошо известном тебе языке — несколько часов. Меня 3 года назад в процессе трудоустройства еще и посадили на Mac (который я до того видел раз в неделю) — через два часа там бегал LAMP стек с отладчиком, остаток дня настраивал аккаунты, на следующий день пошла более-менее адекватная работа. Заставь меня сейчас учить SCALA — подобного я гарантировать не смогу. Другими словами, я не готов признавать свою профессиональную несостоятельность, если я не способен за те же сутки-двое выйти на адекватную производительность на новом языке.

P.S. Местоположение кофе-машины вообще-то надо выяснять еще на собеседовании :) Полу-шутка.
Очень странно соотносить Verilog / HDL с языками программирования. Человек с таким основным пунктом в резюме — это скорее инженер с более глубокой базой нежели обычный программист, к сожалению уровень зп в России не отражает данную действительность.
Средняя з/п в $70k для самого дорогого языка — это смех.
Средний DBA у нас получает $80k.

Что касается Clarion — отмирающий язык.
Писал на нем 12 лет, живу рядом с головным офисом SoftVelocity. Там все плохо.
Средняя з/п в $70k для самого дорогого языка — это смех.

Это среднемировая зарплата, она вообще ничего не показывает.
Добрый день, если в Вашей компании средняя з.п. $80k, еще не означает, что она средняя з.п. по рынку.
Нам кажется, что у вас не репрезентативная выборка.
Я не упоминал нашу компанию.
Под «нас» я подразумевал регион.
По 1 региону не совсем верно судить о средней з.п.

Если быть точным в терминологии, то он в штате, а не в регионе.

Речь о среднемировой ЗП, а не о среднештатовской. Ну и это ж не 50-я процентиль, а среднее арифметическое.

Ответ хороший, но в таких случаях принято вместе со средним указывать и дисперсию.
самые опытные программисты пишут на Cobol и Perl.
Самые опытные программисты крестятся двумя перстами.

Прочитал «крестятся двумя крестами» и подумал про C++.

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

Позволю с вами не согласится. Вы судите по верхам, а если заглюнуть в глазки, то увидишь клад какого не видал. Поработайте на Tcl и получите несказанное удовольствие. Могу на любом, но на Tcl/Tk блаженствую.

Судя по постам на хабре, Tcl/Tk активно не используется никем кроме Вас, по крайней мере, с 2016 года.
Это не так

А как вам это:


November 04 — 08, 2019
Crowne Plaza Houston River Oaks
Houston, Texas, USA


17th European Tcl/Tk User Meeting
Date
June, 29th and 30th 2019
Location
SUSE headquarters in Nuremberg, Germany

Вы извините, но все эти анализы — туфта. По Клариону — людей с опытом от силы тысяча по всему миру. Из них все уже в работе, десятилетиями. Те что висят с резюме — в Кларионе разбирается от силы десяток из них, нашы HR-ы в этом убедились уже. Как и с Коболом, по Клариону есть затребованность, но проблема в Кларионе как и в Коболе в том что их поддержка — бросание хороших денег вслед за плохими, эрго бессмысленны.
Мы анализировали спрос и количество резюме, у нас не было задачи оценить сколько из общей массы действительно хорошо знают Кларион, тем более что метрики «действительно хорошо» у всех свои.
APL видимо всегда будут обходить стороной.
Никому не охота больше работать с этой монструозной клавиатурой.
Я решила собрать все ваши комментарии и провести еще один анализ.
А вот на мой вопрос не ответили. Повторю — вдруг ответят:
Интересно: кто как оценивает тенденцию (м.б. своя оценка или оценка из сетки):
количество ЯП, пользующихся спросом в мире и РФ:
1) растет;
2) уменьшается;
3) в среднем стабилизировалось: примерно сколько старых ЯП теряют спрос — столько новых получают.
1)На первый вопрос очень просто ответить: js, python, с++, Kotlin
2) c#, objective c
3) Сложно с ходу ответить, нужно подумать.
Спасибо. Буду ждать овета на 3й вопрос.
Почему C++?
НЛО прилетело и опубликовало эту надпись здесь
Довольно долго в своём резюме упоминал Scientific Vector Language, пока не понял, что это бессмысленно, так как про него никто не знает. Язык этот очень узкой спецификации, которым владеют ну пара сотен человек во всём мире.
Пример
// Two-center corrections to the core fock matrix
function calc_F2[]

        F2 = rep [ rep[0,numbf], numbf ];
       	local dD = apt peek [D, x_id D];

        local ibf = 0, iat, jat, i, j;   // bf number of the first bfn on iat
        for iat=1, nat loop
            local jbf = 0;
            for jat=1, nat loop
                if iat <> jat then
                    local gammaij = gamma [ iat, jat ];
                    for i=1, atoms.nbf(iat) loop

                       	local v = peek [ F2, ibf+i ];
                       	v[jbf+igen atoms.nbf(jat)] = get[ F2(ibf+i), jbf+igen atoms.nbf(jat) ] - 0.25 * gammaij * get[ D(ibf+i), jbf+igen atoms.nbf(jat) ];
                       	F2 = poke    [ F2, ibf+i, v ];
                       	F2 = apt put [ F2, ibf+i, v ];
                       	F2(ibf+i)(ibf+i) = F2(ibf+i)(ibf+i) + 0.5 * gammaij * add get [dD, jbf + igen atoms.nbf(jat)];
			F2 = apt put [F2, x_id F2, put [ apt peek [F2, x_id F2], jbf+igen atoms.nbf(jat), 
			                           get [ apt peek [F2, x_id F2], jbf+igen atoms.nbf(jat) ] + 0.5  * gammaij * D(ibf+i)(ibf+i) ] ];
                    endloop;
                endif;
                jbf = jbf + atoms.nbf(jat);
            endloop;
            ibf = ibf + atoms.nbf(iat);
        endloop;

endfunction
НЛО прилетело и опубликовало эту надпись здесь
Бобик хорош. Его PARSE даже в perl портанули, какие-то энтузиасты.
где Brainfuck?
думаю есть указавшие в резюме, но врдя ли есть спрос=))
Мы делали анализ на основе запроса от пользователей хабра, они не вспомнили этот язык.=)
GPSS не увидел в списке. Если уж VHDL есть, то гулять — так гулять!
ИМХО сопоставлять HDL языки и языки написания ПО — это то же самое что сопоставлять таксиста и тракториста. В принципе 4 колеса и баранка есть в обоих случаях, на этом общее заканчивается.
Владение HDL языком — это свойство разработчика РЭА или разработчика микроэлектроники. Само по себе оно не ценится. К нему обязательно должен прилагаться набор скиллов ничего общего с программированием не имеющий.
А в чём разница в скиллах написания кода hdl и высокоуровневого?
Ценится ли само по себе владение С?
В том что это составляющие части другой профессии.
Я программирую на Verilog/VDHL, а помимо этого разрабатываю электрические схемы, трассирую печатные платы, моделирую Signal и Power Integrity и работаю с КИ-аппаратурой. То есть общего у меня с программистами всего да ничего.
Другая корзинка.
В нашем мире — «знать Verilog» — это просто плюс в карму, а не флагман умений.
Хотя для HR мы все одинаковые чумазики ).
То же самое относится к Tcl. Как тут верно было подмечено — он используется в тулах для разработки FPGA, а также он используется в ECAD системах и в системах моделирования SI. То есть знание Tcl — это просто кусок владения САПРом а не самостоятельное умение.
PS: HDL — это высокоуровневые языки. Низкий уровень в нашем случае — это нетлист.
Ну я встречал на собеседованиях версии, что вот пусть один придумывает, схемотехник разводит схемы, другой моделирует, следующий тестирует, а вы извольте только вериложить алгоритм уже отлаженный.
И в этом подходе ну вообще никакой разницы не вижу…
Ну где такой отлаженный алгоритм — там и зарплата 40 тыщ у «Verilog-программиста». Это достаточно простой язык — на такие позиции можно смело брать студентов и через полгода они уже будут нормально кодить Verilog без детских ошибок. А просто написать что-то там внятное — недели через две наверное смогут.
Если полноценные профессии подвергнуть декомпозиции на скиллы, а потом скиллы называть профессией — то да, разница не большая. Как в примере с таксистом и трактористом — скилл кручения баранки у них одинаковый, просто немножко разные баранки. То есть можно посравнивать — что популярнее — тракторная баранка или автомобильная. Какая там… легче крутится, удобнее в руке лежит.
А аналогичный пример про Си не работает?
И нет, там не 40 тыщ предлагали…
А аналогичный пример про Си не работает?

Вы несколько подменили мой посыл. Идея моего поста была такая что автор по сути анализировал каким программистом быть лучше, но при этом засунул в виды программистов скилл от разработчиков электроники.
Разработчиком электроники сейчас в нашей стране быть хуже чем разработчиком ПО. За это платят гораздо меньше.
Разработчиком микроэлектроники быть лучше (чем разработчиком электроники) — за это платят больше. Я бы даже сказал — платят хорошо. Но мест где можно работать — мало.
И нет, там не 40 тыщ предлагали…

Видимо хороший работодатель. А сколько предлагали? А то может я все брошу и займусь — я люблю писать на HDL. Но никак не найду того, кто бы за это платил нормально.
А остальные языки это не скиллы, т.е. просто инструменты для реализации алгоритмов? Без знания предметной области их применять можно тоже только на готовенькие пошаговые пункты отлаженного задания.
Нормально понятие относительное, я вам скину в личку ссылку на хх.
А остальные языки это не скиллы, т.е. просто инструменты для реализации алгоритмов?

Безусловно, просто контекст статьи — ПО. Разработчики ПО могут там навыбирать себе портфолио языков руководствуясь их востребованностью и ценой.
Мы нет — у нас их два + System. Знать по хорошему надо все ).
Человек не выбирает между C и Verilog. Тут он выбирает между тем быть ему программистом или схемотом.
А эмбеддер, который пишет на Сях не должен знать всё, что вы перечисляли выше?
Или всякие попытки HLS И тому подобные попытки перехода с программирования?
Ну и чего плохого в выборе между программизмом и схемотехникой?
Эмбеддер — это все таки программист, который немного погружен в железо. Немного. Обычно они владеют базовыми навыками: умеют читать схемы, работать с КИ-аппаратурой и паять. Этого как правило для их задач — достаточно.
Эдакий гибрид эльфов и гномов. Примерно 85% эльфа и 15% гнома.
Или всякие попытки HLS И тому подобные попытки перехода с программирования?

HLS годится во многих применениях, но процессорные ядра и другие СФ-блоки все таки пишутся на HDL разработчиками микроэлектроники, а не бывшими например Jawa программистами. Тут нет кросс-платформенности специалистов )
Ну и чего плохого в выборе между программизмом и схемотехникой?

А я разве говорил что это плохо?
Да ладно, бывает и наоборот — электронщик, освоивший программирование.
Бывает и врачи становятся программистами.
Частные случаи на то и частные.
Это две разных профессии. Да они идут рядом и связаны. Бывают даже специалисты в обоих сразу. Причем я не о схемотах, умеющих программировать микроконтроллеры — это добра полно. А а полноценных профи в обоих классах)
Но в общем и целом эти профессии — разные.
А у вас есть статистика?
Может, это у вас частный случай. Или оба варианта одинаково распространены. Утверждать ничего не могу.

Но ведь есть целая специальность 210202 (ранее — 220500) «Проектирование и технология электронно-вычислительных средств», выпускникам по которой, по идее, в эмбеддеры прямая дорога.
Вот смотрите — запрограммировать STM32 чтобы он правильно дрыгал ногами и читал I2C — я смогу.
А написать ПО сопровождения цели в реальном времени для PPC440 — нет.
Этим и отличаются схемоты, умеющие программировать микроконтроллеры от разработчиков встраиваемого ПО (эмбеддеров).
А можете привести источник, где вы взяли такое определение слова «эмбеддер»?

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

Ну и ваши личные нюансы — вообще не аргумент.
Соглашусь что я возможно вольно обращаюсь с понятиями. В моем окружении словом эмбеддер обычно называют программистов, которые пишут софт для микроконтроллеров.
НЛО прилетело и опубликовало эту надпись здесь
Некоторая польза всё же может быть. Для меня из этих данных стало открытием, что в РФ так мало специалистов vhdl/verilog, интуитивно ожидал на несколько порядков больше. Понимаю, что цифры неточны, но имхо общий порядок прикинуть из них можно.
> За последние три года в моё агентство ни разу не поступал запрос
> на поиск Perl разработчика в новый IT проект или стартап.

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

Публикации

Истории