Все языки эквивалентны. Но некоторые из них эквивалентнее другихСайт tiobe.com регулярно нас знакомит с рейтингами языков программирования. Перед вами — рейтинг от декабря 2011 г.
* — нет данных Какие выводы напрашиваются, глядя на эти данные?
Рейтинг языков программирования в РоссииОн составлен на основе открытых вакансий на сайтах job.ru, rabota.ru, hh.ru и других. Это не первое исследование на такую тему, но оно единственное, которое учитывает факт существования 1С. Такое игнорирование 1С в других рейтингах нелогично хотя бы потому, что продукт аналогичного класса ABAP включен в рейтинги как Tiobe, так и в некоторые отечественные. Напомню, что ABAP — это внутренний язык программирования автоматизированных систем управления предприятиями SAP R/3.Нет оснований говорить о совершенства метода подсчёта востребованности языков программирования. Существование вакансий не является полным описанием ситуации. Но другой работающей методики в России пока нет. Теперь пояснения к таблице. Поскольку объявления о найме специалистов содержат, чаще всего, не одно требование к соискателям, то учёту подлежали следующие данные. Для колонки «Основной язык» учитывались те инструменты, которые стоят в объявлении первыми. Остальные инструменты учитывались для колонки «Дополнительный язык». На основе этих данных подсчитаны рейтинги «основной язык» и «дополнительный язык». В общий рейтинг попали данные по колонке «основной язык» и данные по колонке «дополнительный язык» с коэффициентом 0,5. Решение, возможно спорное, но дополнительные требования, как правила мягче и не всегда обязательны. Должны же отличаться весом «основной язык» и «дополнительный язык»! И последнее замечание: в рейтинг не вошли языки разметки вроде HTML в виду того, что они не являются полноценными языками программирования. Хотя языки SQL тоже таковыми не являются, но они достаточно развиты и они есть в рейтинге Tiobe.
А здесь какие выводы можно сделать?
Смотри так же:Что ещё почитать на эту тему
Опубликовано: 2012.09.25, последняя правка: 2015.01.23 03:32
Отзывы
Это также наглядно отражает графа "Как дополнительный язык". Я думаю корректным было бы сравнение в разрезе специализации - универсальные языки нужно сравнивать между собой, а не с языками БД и пр.
Рейтинг — он на то и рейтинг, что показывает сегодняшнюю температуру по больнице. Но некоторым прозорливым людям он даёт пищу для размышлений. Вопрос же, что лучше, а что хуже, тут даже не стоит. Медики давно говорят, что продукты без холестерина полезней, однако сильно это меняет наши прилавки?
1C — это «наше всё». Или как минимум стабильная з/п и надежда на пенсию.Кажется большинство програмистов в России работают бухгалтерами, колымят делая сайты-визитки и по вечерам озверев от такой жизни фигачат вирусы на C++. Как хорошо, что я не работаю программистом :-) Чистый C опережает C++ в два раза на мировых площадках. Но в России всё наоборот: C++ опережает C просто на порядок! А может для С поиск производился только по латинской "C"?
Как хорошо, что я не работаю программистом А кем Вы работаете?А может для С поиск производился только по латинской «C»? Поиск производился по разделу «ИТ» с выбором региона «вся Россия», а далее — ручной подсчёт.
Место Язык БаллыИсточник: IEEE Spectrum
Все названия языков — условные, это названия целых групп. Точка отсчета — "машинный язык" <0,0>. От неё можно идти вдоль двух осей: по абсциссе — интерпретаторы, "языки, понимающие, что пользователь хотел сказать"; по ординате — компиляторы, "языки, лучше пользователя знающие, что он хотел сказать". Единичный компилятор — C <0,1>. Единичный интерпретатор — FORTH <1,0>. BASIC <1,1> — это объединение интерпретатора и компилятора для удобного решения сиюминутной задачи программирования. Если мы хотим вылезти за пределы этого единичного квадрата, имеет смысл считать BASIC новой точкой отсчета, новым "машинным языком". Прямой же выход за пределы квадрата: например ещё более "знающий" компилятор (C++) <0,2> или ещё более мощный BASIC (MS Visual Studio со всеми её "бейсиками#" в единообразном обезьяннике) — лишь плодят трудности в понимании языков, а не увеличивают возможности программирования. "Теоретические" языки я вынес в другую плоскость, начиная с Машины Тьюринга <-1,-1>, Algol <-1,1>, Lisp <1,-1>, Машины пятого поколения <2,-1>... Можно проследить, как "один язык", в зависимости от реализации может попасть в разные квадраты. Например Pascal изначально был в группе Algol, хоть как-то реализованный (UCSD, Turbo) — уже C, а с правильным обезьянником — Delphi — перерос в супер-бейсик MS VS. Или изначальные C и FORTH, пострадавшие от ANSI, немного поползли за пределы квадрата.
Сами языки не накладывают каких-то ограничений на способ преобразования исходного кода и исполнения. Для тех же Си и Паскаля есть и компиляторы, и интерпретаторы. Единственное ограничение со стороны интерпретируемых языков — это наличие в них функции eval. То есть интерпретация кода на лету. Но в Clipper наличие такой функции не мешало получать файл *.exe. Видимо, компилятор встраивался в исполняемый код. Так что идея изобразить всё это на двухмерной системе координат видится неудачной. Когда-то Япония распиарила свой проект создания машин пятого поколения. Но, несмотря на гигантские вложения, всё закончилось пшиком. Одна из причин — ставка на язык Пролог.
Разумеется, я могу наделать разделов у себя на форуме. Но там это всё-таки лишнее, так как мой форум разработке языков не посвящён.
Каждую фичу надо изучить глубоко и не предвзято. У себя в разделе «Анализ и критика» пытаюсь это делать. Что-то выходит, что-то не очень. Например, как реализовано взаимодействие чистой и «грязной» части в языке Хаскелл — я так и не развеял туман. Кто бы это сделал, да так, чтобы «ежу было понятно»?
Есть тема, которую собираюсь расширить и углубить в ближашее время. Сделаю это, держа в уме, что я работаю над языком системного программирования. Но у Андрея Бреслава или Игоря Томасова другой взгляд на применение языка, поэтому для будущего обзора было бы полезно привлечь разных авторов с разным углом зрения. Хорошо бы найти энциклопедиста типа Дональда Кнута, но где ж его взять? Так что даже не знаю, как быть. Всякого рода форумы или телеграмм-каналы явно не подходят по формату, в них нет систематизации, что важно для научных знаний. Неплохо было бы подумать завести какую-то wiki-энциклопедию, чтобы желающие могли там что-то изложить (обещаю вносить туда свой вклад, если она появится). Даже могу подсказать: есть такая progopedia.ru, это весьма подходящая площадка для такой темы. Но там всё заглохло, регистрации нет, администратор сайта — киевлянка, и не ясно, насколько она заинтересована в развитии своего сайта и в контактах с жителями РФ. Возможно, надо будет создать с нуля что-то похожее. И даже сделать более широкий охват тем. Но это Ваша стихия — что-то планировать, так что планируйте. Это всё, что я имею сказать в настоящее время P.S. Прогопедия, оказывается, не работает. В вэб-архивах только осталась. Значит, о ней можно забыть.
языков уже больше 10 000 (несколько лет назад говорили о 8 000 ... Есть сайт distrowatch (https://distrowatch.com/), на нём элементы рейтинга отсортированы по убыванию популярности. А сам этот рейтинг составляется по собственной статистике обращений самого сайта distrowatch. То есть всё совершенно локально, автоматизированно (не требует внимания), расширяемо, интересно само по себе (что сейчас актуально, что нет).Так-то дистрибутивов тоже немало, но это интерфейсу сайта совсем не вредит. И пообсуждать можно каждый, и всё самое ходовое на верху, и время тратить надо только вначале на то, чтобы настроить движок. реализовано взаимодействие чистой и «грязной» части в языке Хаскелл Монадами же. Описано уже по всему интернету.Кто бы это сделал, да так, чтобы «ежу было понятно»? Ну, мог бы БудДен, но он не будет, ему не надо. А у меня лапки.Неплохо было бы подумать завести какую-то wiki-энциклопедию, чтобы желающие могли там что-то изложить (обещаю вносить туда свой вклад, если она появится). У нас уже есть (точнее была, недоступна, но может оживёт) такая (она не то, чтобы взлетела, просто информирую о существовании): [https://тхаб.рф/wiki/Служебная:Новые_страницы](https://xn--80ac3cm.xn--p1ai/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F: %D0%9D%D0%BE%D0%B2%D1%8B%D0%B5_ %D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D1%8B) Я считаю, что надо делать специализированный движок (но мнения, каким образом он должен быть сделан, расходятся, поэтому несколько). это Ваша стихия — что-то планировать, так что планируйте Вызов принят, только попозже, я сейчас на миссии.
Монадами же
Вы прямо проситесь стать энциклопедистом в будущей энциклопедии. Поэтому подсказываю, чего не хватает. Опишите, пожалуйста, монаду IO. Прямо по байтам. Сколько там байтов, какое у них назначение. Как передаются функциям параметры типа IO: порядок укладки их в стек. Порядок вызовов подпрограмм и возврата управления. Приведите код на ассемблере. Со всеми подробностями. А у меня лапки Ну так посмотрите на ёжика на картинке выше, у него тоже лапки, но, к сожалению, проблемные. Но мордочка-то умная! И это даёт надежду. Так что дайте повод надеяться и на Вас.
чего не хватает. Опишите, пожалуйста, монаду IO. Прямо по байтам. Сколько там байтов, какое у них назначение. Как передаются функциям параметры типа IO: порядок укладки их в стек. Порядок вызовов подпрограмм и возврата управления. Приведите код на ассемблере. Со всеми подробностями. Все функции одинаково вызываются, и это ничем не отличается от разных соглашений вызовов (https://en.wikipedia.org/wiki/X86_calling_conventions)_cdecl: ; прямой порядок расположения данных на стекеФишка такого компилятора не в том, как он функции преобразовывает в ассемблерный код, а в том, что он знает про монады, и как проверяет остальной (проверяемый) код. Т.е. фокус на изучение вы мне не на то направляете.
Все функции одинаково вызываются И при этом Вы приводите примеры вызовов в Си. А вас же просили:Опишите, пожалуйста, монаду IO. Прямо по байтам. Сколько там байтов, какое у них назначение. Как передаются функциям параметры типа IO: порядок укладки их в стек. А это про Хаскелл. А в Хаскелле функции каррированные (то есть вызов функции сn аргументами превращён в n вызовов по 1 аргументу). И в стек попадают не копии параметров, а их адреса — по логике для нескалярных объектов должно быть так, а как на самом деле — не нашёл информации, чтобы всё было расписано по байтам.Зря я с Вами это обсуждаю. Ведь изначально разговор вроде был про некую энциклопедию фич языков программирования, и возражений, как вижу, не последовало. Значит, туда и надо двигаться.
есть такая progopedia.ru, это весьма подходящая площадка для такой темы. Но там всё заглохло, регистрации нет, администратор сайта — киевлянка, и не ясно, насколько она заинтересована в развитии своего сайта и в контактах с жителями РФ.
С другой стороны, а кто это будет делать? Например, есть такая хорошая книга (хоть и устаревшая) Р. Себесты — «Основные концепции языков программирования». Несмотря на то, что там концепции только основные, в книге 659 страниц. А какой объём она заимеет, когда вберёт в себя все? А фича — более мелкая деталь в сравнении с концепцией, значит описывать придётся ещё больше. Найдётся ли такой современный Дональд Кнут, который посвятит свою жизнь тому, чтобы всё это описать? Есть например, такая вот книга:Н. Н. Непейвода, И. Н. Скопин, Основания программирования. Москва-Ижевск: Институт компьютерных исследований, 2003, 868 с., ил. Описание: https://www.osp.ru/os/2004/02/183951 Содержимое гуглится, например: https://reallib.org/reader?file=479309&pg=1 Мне в целом нравится "полиглотный" подход авторов: когда изложение понятий и концепции происходит с нескольких сторон, то есть "изложение понятий происходит в их взаимосвязи и взаимозависимости". То есть: основные концепции, понятия, парадигмы и модели, методы программирования, технологии программирования. Понимание методов важнее знания большого количества фактов — если понята система, как их можно вывести.
Монада суть моноид в категории эндофункторов Вот спасибо! А мужики и не знали. А что не так с этим определением? Оно интуитивно понятно же. Вот смотрите, на пальцах. Есть универсальная сущность "объект в категории" и преобразования сущности, "стрелки" вида "морфизм, отображающий объект самого в себя". Например: моноид — это понятие, аналогичное алгебраическим: кольцо, поле, группа, группоид.Берём, например, число и морфизм. PLUS(0;+;N) на поле натуральных N. Первое — нейтральный элемент. Второе — конструктор нового из старого третьего N и нейтрального. Или другой моноид: MULT(1;*;П). Первое — нейтральный элемент. Второе — умножение простых чисел. Третье П — простое число. Теперь делаем моноид моноидов, композицию моноидов MULT и PLUS. Получаем новый моноид-конструктор, способный из простых сгенерировать всё поле натуральных чисел. Можно взять и другие "объекты" и "морфизмы" — не обязательно числа и операции. Например, строки составленные из символов и гомоморфизм — операцию конкатенации. Или списки, деревья, матрицы. Или S-выражения Лиспа, стековые выражения Форта, R-выражения рефала. Или, например, изобразить на моноидах объектно-ориентированное программирование. В ООП-модели языка Смоллток: объект это инстанс сущности класс, которая инстанс сущности метакласс, которая инстанс сущности метакласс которая... (получаем зацикливание, то есть, объект/класс/метакласс замкнут сверху; но можно замкнуть, например, и снизу, взяв прототипное ООП в духе Io или Self и изобразив метаметаобъект/метаобъект/объект/... и метаобъектный протокол в духе AMOP из CLOS из Common Lisp например) объект — это моноид вида OBJECT(NullObject;send;OBJECT). Здесь send — это морфизм вида "посылка сообщения". NullObject — нейтральный объект; который базовый Object, не содержащий никакой функциональности, кроме: doesNotUnderstand-метода. Send посылает сообщение другому объекту, и если он его не понимает (doesNotUnderstand) — то ищет другой — тот, который его поймёт. Например, метод предка. Или паттерн типа proxy. Например, нечто вроде "категорий интерфейса" в Objective C (который по сути Си+Смоллток) и метода poseAs. То есть: "Нейтральный объект" — это базовый объект, не умеющий ничего, кроме посылки сообщений (неизвестно кому). "Морфизм" — это обобщённый интерфейс объекта, со всеми его разновидностями (наследование, полиморфизм, сокрытие информации, делегирование). Например, интерфейс интерфейса. Иначе говоря — "метаобъектный протокол". Вы прямо проситесь стать энциклопедистом в будущей энциклопедии. Поэтому подсказываю, чего не хватает. Опишите, пожалуйста, монаду IO. Прямо по байтам. Сколько там байтов, какое у них назначение. Как передаются функциям параметры типа IO: порядок укладки их в стек. Порядок вызовов подпрограмм и возврата управления. Приведите код на ассемблере. Со всеми подробностями. Это неважно. Так же, как для объекта при инкапсуляции важна суть поведения — а не его реализация. Можно объяснить по другому: монада в Хаскелле — это способ локализации, изоляции побочных эффектов, так же, как и модуль, или компонент, или класс или объект. Например, вот есть глобальные переменные. Или переменные модуля. Или переменные-член объекта. Или погружённые в замыкание — вложенные области видимости. Способ локализации и изоляции побочных эффектов.Объекты здесь тайпклассы и поэтому можно легко создавать интерфейсы высшего порядка. Например, трансформации, выражающие трансформацию. Применением композиции каких-то стандартных монад. Вот, например, паттерны проектирования в ООП. Если внимательно посмотреть классическую книжку "банды четырёх" про реализацию одних и тех же паттернов на С++ и на Смоллтоке — то можно увидеть общие идеи: 1. Заменить более жёсткий тип связи типа наследования более гибким типа агрегации или композиции, то есть, вложения. 2. Заменить стереотипы и ассоциации каким-то непонятным интерфейсом "метаобъектного протокола" или полиморфизмом высшего порядка. 3. Используя ковариантность/контрвариантность, обеспечить согласованное изменение связанных однотипно объектов. Тут на С++ мало что понятно ибо он инвариантен. А вот на каком-нибудь Eiffel тут была бы конструкция A: LIKE ? ; или A:LIKE B — ковариантность для реализации. 4. Согласованного изменения пары связанных типов классов вниз по иерархии наследования/ 5. Cогласованное изменение пары связанных экземпляров — с контролем их времени жизни. В общем, в эту тему интересна презентация из лаборатории Касперского на тему "реализация базовых паттернов ООП из GoF банды четырёх на языке Haskell" Там можно увидеть как получается ещё короче чем в Смоллтоке со всеми этими полиморфизмами высшего порядка, классами типов, типами классов, стрелками и объектами, монадами. Но, в отличие от того самого динамически типизированного, но медленного диспетчеризируемого Смоллтока — быстро и типобезопасно.
А это про Хаскелл. А в Хаскелле функции каррированные (то есть вызов функции с n аргументами превращён в n вызовов по 1 аргументу). И в стек попадают не копии параметров, а их адреса — по логике для нескалярных объектов должно быть так, а как на самом деле — не нашёл информации, чтобы всё было расписано по байтам. В Хаскелле GHC, например, когда-то применялся язык C-- только это не другой С-- (кого надо C--):https://mail.haskell.org/pipermail/glasgow-haskell-users/2005-October/009194.html https://en.wikipedia.org/wiki/C-- https://github.com/japesinator/CMHaskell Это не тот https://habr.com/ru/companies/kolibrios/articles/303582/ C--, который SPHINX C-- by Peter Cellik (в некоторых версиях его доработали, например, Михаил Шекер до возможности генерации Win32 приложений, см. https://github.com/jossk/c--sphinx). Вот тут, например, доработано до поддержки Win32 и Linux: http://board.kolibrios.org/viewtopic.php?t=3237&start=120. Ещё где-то видел кажется как писать win64 хелловорды на этом вот C--, но сразу так и не вспомню. Да, так в Хаскелле GHC другой Cmm=C--=Cminusminus. Который использовался для IR компилятора и кодогенератора. Примерно с теми же целями что и в Cyclone, BitC, ShenLisp использовалось "согласование типов, задаваемое пользователем". Потом частично бекенд GHC переписали, в основном под LLVM. Подозреваю, что ABI-зависимые вещи типа соглашения о вызовах и конкретной раскладки по байтам надо искать где-то там — в Cmm бекенде. Одно это требование про каррирование уже тянет за собой сборщик мусора, например. Другое дело, что некоторые сборщики мусора могут быть довольно просты и при этом довольно производительны. Например, на сайте justine.lol про sectorlisp приведён довольно простой сборщик мусора в пару десятков байт размером. Ephemereal generational GC может работать довольно быстро, например, выделять память за O(1). Хотя "сборщик мусора реального времени" и прочая realtime JVM RTOS лично для меня всё-таки воспринимается как оксюморон, скорее.
А что не так с этим определением? Оно интуитивно понятно же. Вот смотрите, на пальцах. Объяснения совсем «не на пальцах». Среднему программисту слова «объект в категории», «моноид», «стрелки», «морфизм», «ковариантность» — это ни о чём. Про стрелки программист переспросит: а какую стрелку имеют в виду? В Юникоде много стрелок.Раньше программированием занимались люди, у которых в дипломе была написана специальность «инженер-математик». Им преподавали высшую математику. Один из моих знакомых безуспешно пытался легализовать свой диплом в Германии, указывал им: смотрите, у меня в дипломе написано, что часов по математике мне дали больше, чем дают в вашем университете Гумбольдта. Но и такие люди часто не въезжают, что значит «моноид — это понятие, аналогичное алгебраическим: кольцо, поле, группа, группоид». Есть такой известный блогер Олег Макаренко (он же Фриц Морген), бывший программист. Не знаю, каким он был программистом, но его единственное образование — «религиоведение». Есть знакомые программисты (надо заметить — хорошие программисты), которые вообще не имеют высшего образования. Но если бы их работа засчитывалась только тогда, когда они отчитаются о ней в терминах моноидов да группоидов, то они перестанут быть полезными обществу. Если бы у нас в профессию допускали только тех, кто оперирует такими терминами, то с работой попрощалась бы большая часть разработчиков. А страна осталась бы у разбитого корыта в плане разработки собственного ПО. Герман Греф вообще высказался, что навыки важнее знаний. Не согласен с ним, но сейчас куда меньше смотрят на диплом, всё больше на опыт работы.
часто не въезжают, что значит
Это неважно. Пренебрежение к «неважным» вещам приводят к эпическим провалам. Мне удалось добиться разницы в скорости программ на Си и Хаскелле в полторы тысячи раз! И это не предел. Одна из причин, почему Хаскелл так мало используется, как раз в этом и заключается. В компьютере есть всего две сущности: данные и машинный код, который этими данными пользуется. Всё остальное накладывается сверху этого. Неумение объяснить суть этих наслоений ведёт к игнорированию тяжело понимаемых теорий.Одной из желаемых целей является простота языка: «Простота является самостоятельной ценностью». Изоляции побочных эффектов можно достичь простыми способами без привлечения терминологии, которая неизвестна людям со средним образованием. Например, все «нечистые» функции могут быть вынесены из функции и переданы ей в качестве параметра. Тогда функция, которая только что была «нечистой», превращается в условно чистую функцию. То есть её чистота зависит от условия, является ли переданная ей в качестве параметра функция чистой или нет. Это можно объяснить на двух пальцах, в отличие от «экзистенциальной квантификации». «Физик должен уметь объяснить простой уборщице, чем он тут занимается».
Опять же, непонятно в каких единицах и на основании чего составлялся измерялся рейтинг. Это что угодно, но не проценты, т.к. их сумма за 80-й год составила 112.402 единицы.
даже его автор не может ответить, откуда статистика Рейтинг TIOBE ведётся с 2002 года, так что он не мог быть источником для видео с рейтингом с 1965 года.
Индекс популярности языков программирования PYPL (PopularitY of Programming Language) создается на основе анализа частоты поиска учебных пособий по языку в Google. Чем чаще ищут учебник по языку, тем популярнее считается язык. Это опережающий показатель. Необработанные данные поступают из Google Trends. Но, как видно из описания на его сайте, он опирается исключительно на Google. В теории можно было бы придумать ещё один рейтинг: по тиражу книг, которые были были посвящены каким-либо языкам. И в теории же можно было бы восстановить рейтинги языков аж с 1950-х годов. Но сегодня такой рейтинг вызывал бы вопросы, потому что книги переходят с бумажного формата в электронный, а как учесть электронный «тираж» — вопрос, что называется, на засыпку.
Опять же удивляет отсутствие в рейтинге языков PL/1 и Forth Первый вроде никогда не был популярен со слов нашего разработчика его компилятора. О проектах на втором вообще ничего не рассказывают. Хотя тут на форуме кто-то писал, что применял.меня удивило первое место в рейтинге языка Ada в 1986 году. Не знаю даже, верить этому или нет Тут ничего удивительного. Холодная война. Пентагон диктовал условия многочисленным подрядчикам, будучи основным заказчиком. Надо учитывать общий уровень развития программирования тогда и качество средств разработки — на Ада получали гораздо меньше ошибок. Программы-то принимались не по лицензии "AS IS" 🤣Ещё и Лисп набирал в Штатах в свое время значительную популярность — но больше в академической среде. По количеству ЭВМ они опережали Советский Союз в разы. Единственное, что показалось несколько странным — проседание показателя Кобола вдвое и затем его восстановление. Написать автору можно на электронную почту |
2014/04/21 06:35, utkin 
