Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Опитування: рейтинг мов програмування

Минув рік з моменту попереднього опитування. Настав час дізнатися, що змінилося за цей час, які мови програмування втрачають популярність, а які — навпаки, набувають послідовників.

Рейтинг мов програмування 2020: JavaScript випередив Java, а Dart увійшов у першу лігу






Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



33 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

В следующий раз, добавьте Elixir

Скільки можна виділяти TypeScript в окрему мову? Це ж просто надмножина, людина яка знає JS почне писати на тайпскріпті за декілька днів. А знати тайпскріпт без JS неможливо. Ця дурня псує всю статистику

Не все так просто як здається, не почне. Тайпскріпт це не просто :number після змінних дописувати, там багато нюансів. Більше того, сам стиль розробки з типізацією відрізняється від чистого JS’а. Можна писати на JS’і і не кумекати TS зовсім, тому на мою думку TS правильно окремо винесли.

Ну звісно що є нюанси. Але перейти з JS на TS не є проблемою. Для досвідчених девів просто посидіти розібратись з документаціюєю. Для менш досвідчених є ментори/код ревью. Це не займає багато часу навіть для цілої команди.

а хіба мова визначається тим на скільки важко на неї перейти з іншої мови?

TypeScript — окрема мова
Не має значення транслятор — важливо якою мовою мислить розробник

людина яка знає JS почне писати на тайпскріпті

так само и з Groovy, Scala та Kotlin — досвіченний розробник на Java теж швидко зможе писати на них як на «покращенній Java».

Але це ж окремі мови? То чому TypeScript , який більш схожий на С# не має права бути виділеним?

різниця між Groovy, Scala і Java сильно більша ніж між JS/TS. В Groovy куча нових фіч і інший синтаксис, в Scala взагалі нова парадигма програмування. Java DEV який перший раз в житті бачить функціональний підхід на те щоб почати нормально працювати зі Scala треба в рази більше часу ніж JS Dev на те щоб розібратись зі строгою типізаціюєю (такою ж як в цілій купі інших мов).

в рази більше часу ніж JS Dev на те щоб розібратись зі строгою типізаціюєю
...
перейти з JS на TS не є проблемою

ну тобто якщо JS Dev швиденько розбереться с Java, то ви скажете що Java це те ж саме що й JavaScript

такою ж як в цілій купі інших мов

ну тобто тоді і немає різниці між Java та C#.

В Groovy куча нових фіч

1. Groovy розроблявся так, щоб Java код був майже завжди валідним Groovy-кодом
2. TS розроблявся так, щоб JS код був майже завжди валідним TS-кодом

але чомусь ви робите різні висновки для TS і Groovy, хоча «формула» однакова
X розроблявся так, щоб Y-код був майже завжди валідним X-кодом

а я от дивлюсь, наприклад
www.typescriptlang.org/...​dbook/advanced-types.html

і не бачу якє це все має відношення до JS
і як JS Dev швиденько те второпає, та почне писати на мові з статичною типізацією та користуватись такими розвиненими засобами, якщо ніколи до цього не мав справу з такими мовами програмування.

Scala взагалі нова парадигма програмування

цій «новій» парадигмі (ФП) більше років ніж ООП.

всім коментаторам до мого коменту відповідаю:
бе-бе-бе
:P :Р :Р

Нас в 90-х вчили вибирати ту мову програмування, на якій ефективніше може бути запрограмовано, розв’язане завдання. Тому варто вміти реалізовувати задачі на декількох мовах програмування.

Це була епоха Fortran, Cobol, C, Assembler, C++. <512MB RAM, max PII-200 :)
Цінували швидкість, простоту, алгоритми.
Зараз це залишилось, але на крутих проєктах типу Windows, Linux, etc.

во времена фортрана и кобола никаких возможностей «реализовать эфэктивнише декилькома мовами» не было был только фортран и только кобол и у system/360 было до 4 МБ оперативки в самом пределе а в базовой версии до 64 КБ

но было смишно пеши исчо ))

во времена фортрана и кобола никаких возможностей «реализовать эфэктивнише декилькома мовами» не было был только фортран и только кобол

Если ты про времена S/360 — то как минимум ещё ассемблер и RPG. После добавился PL/1.

Но он вообще-то про первые поколения поступившего к нам хозяйства линии IBM PC. Можно это было понять по упоминанию C++ :)

и у system/360 было до 4 МБ оперативки в самом пределе

16MB (2**24), таки учи матчасть :) И это с методами тех времён было до чёрта, на таком объёме могло несколько виртуалок крутиться (даже, это уже 370 надо для виртуализации, но я тут про память).

а в базовой версии до 64 КБ

Что такое «базовая версия»? Не считая Model 20 (кастрированную по процессору), начиная с Model 30, можно было получить машину с 8KB. Но на ней и работала обстановка без ОС.

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

В общем, перестань путать и поколения, и ТТХ. Просто обидно за отрасль, когда такое пишут.

16MB (2**24), таки учи матчасть :)

учу у неё адресная шина была 24 бит но это чисто в теории предельные конфигурации были только на 4 МБ и это кастомные и чтобы поменьше выдумывать посмотри на каком принципе чисто физическом там работала оперативка ))

В общем, перестань путать и поколения, и ТТХ. Просто обидно за отрасль, когда такое пишут.

а ну ок ))

посмотри на каком принципе чисто физическом там работала оперативка ))

И на каком же? Если ты про ферритовую — мне не нужно смотреть, я её руками щупал в нескольких вариантах плотности :)

Да, в 70-е типичная укладка была что-то вроде 128-256KB на шкаф такой памяти. Но кто хотел — ставил много шкафов. В 60-е — да, сильно меньше — там и 64KB было чудом.

Исходное поколение 360-х работало, кстати, даже не на планарных микрухах, а на предтестированных транзисторных сборках(!) Уже потом стали переходить на микрухи (а советские ЕСки уже шли только на них). В конце 70-х и память стали на микрухи переводить, стало полегче по объёму :)

предельные конфигурации были только на 4 МБ и это кастомные

Тут с ходу 4 и 6. А кастомные наверняка можно было и больше догнать, где 6, там и 8. Страшно представить, сколько это стоило, но это не моя забота :)

А основная проблема к росту памяти была даже не в том, что дорого — а в том, что смысла не было. Нижние модели исполняли буквально единицы тысяч операций в секунду, старшие — ну, сотню тысяч. Пока ты ту память обработаешь — дешевле записать на диск и прочитать с диска. Активный рост за пределы 1-2MB стал иметь смысл только со следующей волной скорости и с виртуальной памятью. Поэтому я и считаю, что ограничиваться объёмом массовых установок не так важно — всё равно задача важнее, сколько нужно для задачи — столько и ставили.

Но с другой стороны, пусть считаем с поправкой — 6MB в пределе установки (при 16 пределе адресации) в собственно 360-х. Всё равно при тогдашних подходах это просто до чёрта. Оптимизирующий компилятор Фортрана (тип E) выжирал 200-300KB в прыжке и при этом достаточно неплохо уже ускорял (в пределе на порядок). Глючил, правда, зверски — вместо него предпочитали H, который хуже оптимизировал, но был надёжным. Линкер не вылазил за 128KB. Вся ОС в оперативке укладывалась в 200, с запасом. Ну и так далее. И писали тогда долго, но экономно :)

Но всё-таки основная речь шла про 90-е годы. Там уже 8MB было дорогой, но подъёмной настолкой.

а ну ок ))

Договорились :)

Но всё-таки основная речь шла про 90-е годы. Там уже 8MB было дорогой, но подъёмной настолкой.

=>

Це була епоха Fortran, Cobol

скучно с вами реально нереально )) очень Президента вашего напоминает просто 1-1 ))

Це була епоха Fortran, Cobol

Ну и? Может, у него много было Кобола на PC. Я знал одного такое место как раз в 90-е. И ты опять «забыл» про упоминание C++.

очень Президента вашего напоминает просто 1-1 ))

«Нашего» это кого? Если ты про Зелю, он не мой. А твой или нет — решай сам — но судя по бардаку в твоих комментариях, не исключено :)

И ты опять «забыл» про упоминание C++.

и про

PII-200

я же ж говорю скучно «на Буншу нашего похож» (к) (тм)

Для мене часи фортрану і коболу це 95-99 рік ;)
Pascal, C, C++

минус 30 рокив и буде норм понятно всьо это не для 23-литних синьорив ))

Скорее тогда бы шла речь о том, что можно не писать обработку текста год на C++, а быстрее выучить Perl и написать за месяц с учетом изучения Perl.

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

По сути для карьеры достаточно просто решить задачу, чтобы она работала.

7000.

В прошлом году собрали 9200 анкет. Осталось совсем немного и начнем подготовку результатов.

Было бы круто, если бы после кнопки «Далее», пользователя возвращало наверх. Я несколько раз за опрос не мог понять а чо экран белый?

Спасибо, убрали форму из статьи, оставили только прямую ссылку.

Підписатись на коментарі