Комментарии 34
Разработчики всё чаще используют ИИ-ассистентов вроде Claude или Cursor, минуя публичные форумы. В результате метрики, на которых строится рейтинг, показывают рост тех языков, что проще интегрируются с ИИ, и падение тех, что завязаны на ручное кодирование.
По логике должно быть наоборот.
Как обычно, TS и JS разделены, хотя это сиамские близнецы (видно, чтобы жабу не потеснить со второго места), очень странное лидерское место Python - какие у него применения-то реальные, кроме машинного обучения (да и то, на серьезном уровне используют кресты), с бека его активно теснит Go... Научная среда и математика его область, но вроде они не формируют тренды в разработке. Язык-то хороший, просто у многих есть стойкая аллергия на intend-based синтаксис, может, пайтон++ с нормальными блоками в скобках порвет мир. В общем, какой-то слегка оторванный от реальности рейтинг.
Всё чаще требуется дисциплина и переход на TypeScript или ESM
Тут ещё в тексте и ESM дополнительно выделили. Не дай бог это разделение ещё и до рейтинга доберётся.
какие у него применения-то реальные, кроме машинного обучения
В DevOps много пишут автоматизации на нём. С чем, кстати, ИИ неплохо справляется.
Блоков со скобками в Python никогда не будет, ведь именно благодаря их отсутствию он стал таким популярным (и легко читаемым). ИИ на серьезном уровне использует С++, но скрытно (в либах, через обертки). Но сами обертки написаны на Python, и дальше них погружаться нет смысла (да и некогда).
ведь именно благодаря их отсутствию он стал таким популярным (и легко читаемым)
Этому есть подтверждение? (опрос/анализ UX от приличного агенства)
Тут рейтингам целых ЯП никто не верит, а вы про такие UX-тонкости! Впрочем:
смотрим на все рейтинги ЯП, там везде на 1-м месте Python
смотрим чем наиболее он существенно синтаксически отличается от Top-20
отличие по сути одно: отступы, как отказ от { } и "закрывающих" слов типа next итп.
смотрим чем наиболее он существенно синтаксически отличается
Ну вот и следующий вопрос - а почему вы взяли именно эти синтаксические отличия, а не, например, динамическую типизацию, "batteries included" и предельное облегчение интерактивной работы?
А отступы много где есть как синтаксический элемент...
Потому что это самое яркое отличие. Все остальное есть везде и кое-где и получше. Например в VBA в runtime вы после остановки на breakpoint можете сделать две немыслимые веши, которые не даст ни один язык, даже Python, а именно:
отмотать выполняемую строку как угодно далеко назад/вперед и выполнить код
перепечатать (не прерывая отладки) любую строку и повторно ее выполнить
VBA хоронят с момента появления, но он упорно не мрет и живет в рейтингах.
которые не даст ни один язык, даже Python
Это крайне странное утверждение, учитывая абсолютно динамический характер Python:
перепечатать (не прерывая отладки) любую строку и повторно ее выполнить
Я делал такое во встроенном отладчике. Именно динамический характер интерпретатора позволяет сделать вообще всё: пропустить строку, выполнить строку дважды, выполнить её 100 раз, изменить и выполнить - сколько угодно. Чуть больше надо постараться (видел отладчик с таким, не помню уже названия) модифицировать код на ходу, так, чтобы дальше выполнялся модифицированный. Всё это делается, никакого VBA не нужно.
отмотать выполняемую строку как угодно далеко назад/вперед и выполнить код
Вот тут не уверен, что вы имеете в виду. Если просто выполнить код из любой строки, то тоже можно. Если сделать откат состояния программы назад, то я такого не видел, но сомневаюсь, что и с VBA такое есть.
VBA хоронят с момента появления, но он упорно не мрет и живет в рейтингах.
Только для среды Windows, наверно. У меня 99+% всей работы в Unix, в основном в Linux, я его не вижу и про него не помню. Ну да, где-то на другой планете такое есть, только непонятно, зачем туда летать.
По этой вашей странной логике в топе должен быть и Ruby. Что касается "невозможности отказа от отступов" уже есть пример в истории, хоть и не на уровне ЯП, а у CSS-препроцессоров, когда SASS (который шел в комплекте с руби и особой популярности не снискал) оброс скобками, превратившись в SCSS и стал де-факто стандартом во фронтенд разработке до появления PostCSS, что многое говорит об "любви" разработчиков к отступам.
По этой вашей странной логике в топе должен быть и Ruby.
У Ruby роль {} реализована точно так же, "скобками", которые заканчиваются словом end. Оппонент недостаточно чётко выразился, я понимаю, что он имел в виду, хоть и не согласен.
что многое говорит об "любви" разработчиков к отступам.
Я добавлю, что отступы как средство группировки неудобны для поиска границ блоков (особенно если заканчивается несколько блоков) и для ручного рефакторинга в IDE или просто в редакторах. Не знаю, сколько ещё Python будет их держать (или вместо него не придёт другое аналогичное средство), но регулярно это задалбывает.
Неструктурно на Python писать ну очень сложно. За 2 метра до монитора виды блоки кода, в функциях ты просто физически ощущаешь локальное пространство имен. Кодер быстро приходит к тому что вложенности >2 быть не должно, и язык старательно этому учит. Если в IDE включить все плюшки и линтеры, поставить плагины подсветки блоков - реф комфортен.
Есть области где разум пробелов окончательно победил. Я про эволюцию csv - ini - kv - xml - json - yaml - toml.
За 2 метра до монитора виды блоки кода,
Это если они влезают в монитор. Вероятно, у вас 200% зрение. У меня оно "так себе", и я не могу поместить в один экран на постоянную, чтобы работать с ним, более, условно, 30 строк. Конечно, кто-то вспомнит "дядюшку Боба", но функции с блоками на 50-100-200 строк реально бывают, хоть и мало. И вот тут оказывается, что, особенно когда у тебя одновременно закрывается несколько блоков, найти, где они начались - уже квест.
А с языком, где {} (и тем более они обязательны - Go, Rust, много других современных; или C/C++ с форсированной политикой всегда делать блоки, как я всем рекомендую) - перейти к парной скобке это тривиально.
А ещё, когда ты вставляешь блок кода из другого места, IDE с Питоном очень часто ошибается в выборе нужного отступа. Имея же скобки {} или хотя бы then-end, else-end, do-end, etc., такой проблемы никогда не будет.
Поэтому я при прочих равных против выделения отступами и за обязательные скобки блоков кода (лучше символами {}, но и словами тоже пойдёт).
в функциях ты просто физически ощущаешь локальное пространство имен.
И снова - если вся функция влезла в экран. Причём со всеми вложенными, если там есть замыкания.
Кодер быстро приходит к тому что вложенности >2 быть не должно, и язык старательно этому учит.
Ага, тогда вложенность переносится в создание иначе нахер никому не нужных функций с отдельными именами. Причём если в каком-нибудь C++ можно их помечать inline и компилятор тогда их усиленно встроит, в Python это приводит к замедлению "на ровном месте".
Есть области где разум пробелов окончательно победил. Я про эволюцию csv - ini - kv - xml - json - yaml - toml.
Да, я в курсе про YAML (не знаю, зачем вы вспомнили TOML). У него, по сути, те же проблемы -это если не считать того, что формат и в других аспектах чудовищно сложен и запутан - так что он скорее контрпример. JSON с некоторыми облегчениями типа финальной запятой и комментариями, и принудительным форматированием тут был бы полезнее.
Разделяй и властвуй. Функция (UDF) на Python почти обязана влезать в экран, а длина строк д.б. до 120 символов. Если больше - пишем несколько UDF и заворачиваем их в Class, а потом после doctest быстренько прячем в модуль/либу. И замыкания станут не нужны. Хотя я понимаю, немного языков позволяют писать так коротко и кратко. Одни списковые включения [x*2 for x in arr if x>0] в Python чего стоят.
Проблем с копированием кода сейчас почти нет - код от ИИ чист, а код с кавычками-елочками итп дичью - устарел или поеден тем же ИИ.
У Ruby есть закрывающие слова, у Python нет.
+1
У Ruby много чего и более приятного есть, чего у Python нет и не будет никогда. А Ruby тем временем развивается и улучшается - становится всё лучше, удобнее, мощнее и быстрее.
Python выбран математиками за простоту (им ни к чему разбираться ещё и в программировании), а для программиста эта (кажущаяся) простота, зачастую - ущербность.
Рейтинг не измеряет лучший язык, он измеряет шум вокруг языка по определенным метрикам, и шума вокруг Python сейчас объективно больше всего: от школьников, учащихся программировать, до дата-сайентистов в FAANG
Рассуждаем про ИИ-применимость языков, а на самом деле... Ну наверное просто в Дублинской Университетской библиотеке больше книжек по этому языку было
Учитывались: запросы в гугл, стековерфлоу, число уникальных разработчиков, которые сделали коммит на этом языке на гитхабе, число статей с тегом языка в собственной библиотеке IEEE Xplore Digital Library, вакансий на собственном сайте IEEE Jobs Site, сайт Career Builder, количество чат-румов в дискорде, библиотека Trinity College Dublin Library
https://spectrum.ieee.org/top-programming-languages-methodology-2025
как то странно выносить sql как отдельный самостоятельный язык программированя
А кто подскажет, что за язык такой Arduino?
С каких пор HTML стал языком программирования (а не разметки)? Не помню, чтобы он был Тьюринг-полным.
Cuda это библиотека, а не яп.
Разделять JS и TS ну такое. То, что в статье про написано про ESM, это вообще мрак.
Как-то очень, очень слабо для IEEE. Такое ощущение, что писал какой-то студент-гуманитарий, фапающий на Нью-Васюки от ИИ.
До кучи "LabView" написано неправильно, должно быть "LabVIEW".
Arduino - подмножество языка С для микроконтроллеров. На Cuda все настолько другое, что это уже отдельный "язык", как и HTML (вставки на нем есть всюду т.к. браузеры как среда выполнения вездесущи и не использовать их - означает лишить себя больше половины пользователей). Нет разницы на чем написан код - на тьюринг-ЯП, великой библиотеке (Cuda/Pandas/Torch), языке запросов (SQL/DAX/M) или языке разметки (HTML/Markdown/Wiki) - главное что это код. А значит рейтинги разных видоа кодов остаются полезными, они позволяют видеть тенденции новичкам и радоваться старичкам (что они в тренде).
Думаю они включают платформы вроде Arduino и CUDA, потому что для разработчика это отдельные экосистемы со своими правилами, сообществом и рынком труда
Технически это C++ с библиотеками, но в реальности программист Arduino и программист CUDA это разные профессии
Но у JavaScript есть и слабые стороны. Экосистема развивается быстро, и это оборачивается постоянными проблемами с зависимостями, которые ломаются при обновлениях.
А можно какой-то живой пример? И сравнение с соседями по популярности? А то звучит так что текст статьи опоздал на 15 лет.
JavaScript, напротив, теряет позиции: в «Spectrum» он скатился с третьего места на шестое...
Если прям грубо выразиться (простите), то TypeScript это синтаксический сахар для JavaScript :) Ну то есть странно считать их раздельно. А если сложить, то в Spectrum JavaScript будет на втором месте, в Trending на третьем, а в Jobs, внезапно, на первом.
Самое интересное не столько перестановка мест, сколько рефлексия IEEE над своей же методологией, они честно признают, что старые метрики (Stack Overflow, GitHub) начинают врать из за того, что разработчики все чаще решают проблемы, общаясь с LLM в приватном режиме
Рейтинг из меры популярности превращается в меру устойчивости к автоматизации
Мне кажется количество вопросов говорит только о том, что у технологии проблемы с пониманием ее людьми. Python да, лидирует с отрывом :)
Топ языков программирования в 2025 году: рейтинг IEEE и влияние на него языковых моделей