Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Все языки эквивалентны. Но некоторые из них эквивалентнее других

Сайт tiobe.com регулярно нас знакомит с рейтингами языков программирования. Перед вами — рейтинг от декабря 2011 г.
Декабрь
2011
Декабрь
2010
Язык
программирования
Рейтинг
1 1 Java 17,561%
2 2 C 17,057%
3 3 C++ 8,252%
4 5 C# 8,205%
5 8 Objective-C 6,805%
6 4 PHP 6,001%
7 7 (Visual) Basic 4,757%
8 6 Python 3,492%
9 9 Perl 2,472%
10 12 JavaScript 2,199%
11 11 Ruby 1,494%
12 10 Delphi/Object Pascal 1,245%
13 13 Lisp 1,175%
14 23 PL/SQL 0,803%
15 14 Transact-SQL 0,746%
16 16 Pascal 0,734%
17 18 Ada 0,632%
18 35 Logo 0,619%
19 17 Assembly 0,563%
20 25 ABAP 0,560%
21 * Lua 0,550%
22 * MATLAB 0,536%
23 * RPG(OS/400) 0,532%
24 * R 0,522%
25 * NXT-G 0,512%
26 * C shell 0,493%
27 * VHDL 0,480%
28 * Fortran 0,477%
29 * Erlang 0,469%
30 * Scheme 0,456%
31 * SAS 0,417%
32 * Scratch 0,414%
33 * Prolog 0,403%
34 * Go 0,394%
35 * Visual Basic.NET 0,364%
36 * F# 0,358%
37 * COBOL 0,339%
38 * D 0,330%
39 * Forth 0,322%
40 * Haskell 0,310%
41 * Tcl 0,297%
42 * APL 0,287%
43 * ML 0,284%
44 * Ladder Logic 0,281%
45 * Groovy 0,273%
46 * SmallTalk 0,272%
47 * LabVIEW 0,262%
48 * Awk 0,258%
49 * PL/I 0,246%
50 * Q 0,245%

* — нет данных

Какие выводы напрашиваются, глядя на эти данные?
  • Синтаксис в стиле C является доминирующим на данный момент. Этот стиль представлен в рейтинге языками Java, C (родоночальник стиля), C++, C#, Objective C, PHP, Perl, JavaScript. В сумме они занимают, по данным Tiobe, 68,552%. Это «конституционное» большинство.
  • «Старые» языки C и C++ (первый — в особенности) сохраняют и долго будут сохранять свои доли. Тут и громадный пласт унаследованного кода, наибольшего количества программистов, хорошо их знающих. Широчайший выбор компиляторов и других инструментов для разработчиков. И много других исторических факторов. Ещё относительно интересный вывод: несмотря на архаичность языков (в особенности это касается C), мало кто исключает из своего инструментария компиляторы этих языков. Эти языки — такие же стандарты де факто, как и процессоры x86.
  • «Новые» языки могут получить существенную популярность, если за ними стоят гиганты (например, C# с Microsoft за спиной) или группа гигантов, которые «дружат» против других гигантов (Java, с альянсом из Sun, IBM, Oracle — против Microsoft), но ... смотри ниже.
  • Поддержка софтверных гигантов не гарантирует языкам ни быстрого старта, ни значительной доли на рынке. Достаточно посмотреть на место языков Visual Basic.NET, F# (Microsoft), Go (Google).
  • Такие языки, как PHP, Phyton, Perl, Ruby имеют немалую долю на рынке, несмотря на отсутствие подталкивающего «локомотива» за спиной. Более того, их успех феноменален по той причине, что они были созданы одиночками. Но успех к этим языкам пришёл после того, как почин создателей был многократно умножен трудом множества энтузиастов.

Рейтинг языков программирования в России

        Он составлен на основе открытых вакансий на сайтах job.ru, rabota.ru, hh.ru и других. Это не первое исследование на такую тему, но оно единственное, которое учитывает факт существования 1С. Такое игнорирование 1С в других рейтингах нелогично хотя бы потому, что продукт аналогичного класса ABAP включен в рейтинги как Tiobe, так и в некоторые отечественные. Напомню, что ABAP — это внутренний язык программирования автоматизированных систем управления предприятиями SAP R/3.

        Нет оснований говорить о совершенства метода подсчёта востребованности языков программирования. Существование вакансий не является полным описанием ситуации. Но другой работающей методики в России пока нет.

        Теперь пояснения к таблице. Поскольку объявления о найме специалистов содержат, чаще всего, не одно требование к соискателям, то учёту подлежали следующие данные. Для колонки «Основной язык» учитывались те инструменты, которые стоят в объявлении первыми. Остальные инструменты учитывались для колонки «Дополнительный язык». На основе этих данных подсчитаны рейтинги «основной язык» и «дополнительный язык». В общий рейтинг попали данные по колонке «основной язык» и данные по колонке «дополнительный язык» с коэффициентом 0,5. Решение, возможно спорное, но дополнительные требования, как правила мягче и не всегда обязательны. Должны же отличаться весом «основной язык» и «дополнительный язык»!

        И последнее замечание: в рейтинг не вошли языки разметки вроде HTML в виду того, что они не являются полноценными языками программирования. Хотя языки SQL тоже таковыми не являются, но они достаточно развиты и они есть в рейтинге Tiobe.

  Язык
программирования
Как основной
язык
Как дополнит.
язык
Общий
рейтинг
1 30,56% 1,23% 22,13%
2 PHP 18,27% 3,70% 14,08%
3 C++ 12,96% 7,00% 11,25%
4 Java 9,97% 4,12% 8,28%
5 JavaScript 4,65% 16,87% 8,17%
6 Transact-SQL 2,99% 14,40% 6,27%
7 MySQL 0,33% 20,99% 6,27%
8 C# 6,31% 4,94% 5,92%
9 Delphi 4,32% 3,70% 4,14%
10 PL/SQL (Oracle) 1,99% 4,94% 2,84%
11 VisualBasic, VBA 0,33% 3,70% 1,30%
12 Objective-C 1,66% 0,00% 1,18%
13 Perl 0,66% 2,06% 1,07%
14 C 1,00% 1,23% 1,07%
15 Python 0,66% 1,65% 0,95%
16 PostgreSQL 0,00% 3,29% 0,95%
17 ABAP 0,66% 0,00% 0,47%
18 LotusScript 0,66% 0,00% 0,47%
19 Ruby 0,33% 0,82% 0,47%
20 VB.Net 0,33% 0,41% 0,36%
21 MATLAB 0,33% 0,41% 0,36%
22 Clarion 0,33% 0,00% 0,24%
23 ABL (4GL) 0,33% 0,00% 0,24%
  Остальные 1,00% 4,53% 3,31%


        А здесь какие выводы можно сделать?
  • 1C — это «наше всё». Если бы иностранцы вообще и Tiobe в частности познакомились с российкими реалиями, они бы немало удивились. Оказывается, не только Яндекс впереди Google, но язык 1С впереди C, C++ и Java вместе взятых. А ведь эти языки (подумать страшно!) — первая тройка мирового рейтинга.
  • «Победа» 1С, в зависимости от угла зрения, одним может навеять мысли о торжестве «русского» программирования. Другие увидят в этом гипертрофированность фискальной политики государства, благодаря чему здравствует 1С.
  • Чистый C опережает C++ в два раза на мировых площадках. Но в России всё наоборот: C++ опережает C просто на порядок!
  • Невероятная, по мировым меркам, популярность PHP. Список языков, которые в России популярнее, чем в остальном мире: упомянутый PHP, C++, JavaScript, Transact-SQL, MySQL, Delphi, PL/SQL.
  • Список аутсайдеров в глазах российских программистов: C (чистый, без ++: он главный аутсайдер!), C#, Objective-C, VisualBasic, Python, Perl, Ruby, Lisp.
  • Закомерность, не заметная в таблице, но имевшаяся при сборе данных: есть идущие в «связке» инструменты типа PHP, JavaScript, MySQL. Но есть «одиночки», среди которых самый «самодостаточный» — язык 1С.
  • Чем меньше город, тем скуднее выбор «блюд». Это вряд ли новость. Новость в том, что верхние строки рейтинга (1C, PHP) свои показатели в таких городах иногда удваивают. В то время как другие технологии вообще оказываются не нужны.
  • Популярность ABAP, LotusScript, Ruby, VB.Net, MATLAB, Clarion, ABL и остальных — в пределах статистической погрешности.
«Существуют три вида лжи: ложь, наглая ложь и статистика» — это фраза для тех, кто придал слишком серьёзное значение этому небольшому исследованию.

Смотри так же:

Что ещё почитать на эту тему

Опубликовано: 2012.09.25, последняя правка: 2015.01.23    03:32

ОценитеОценки посетителей
   ███████████████████████████ 10 (62.5%)
   ███ 1 (6.25%)
   ▌ 0
   ██████████████ 5 (31.2%)

Отзывы

     2014/04/21 06:35, utkin          # 

Я против такого сравнения по следующей причине: языки имеют слишком различную направленность, рассмотрение их в одном котле не уместно. Например, для профессионалов фактически помимо основного универсального языка обязательно требуется знание одного из диалектов SQL. Это современные требования. Аналогично веб сфера требует знание более одного языка - PHP, JavaScript и пр.
Это также наглядно отражает графа "Как дополнительный язык". Я думаю корректным было бы сравнение в разрезе специализации - универсальные языки нужно сравнивать между собой, а не с языками БД и пр.

     2014/04/24 18:53, Автор сайта          # 

А кто нас, собственно, спрашивает, «за» мы или «против»? Работодатели кидают свои объявления в общий котёл. А мы из него вылавливаем подходящее, одновременно наматывая на ус, за что больше платят.

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

     2015/01/23 22:08, rst256          # 

1C — это «наше всё».

Или как минимум стабильная з/п и надежда на пенсию.
Кажется большинство програмистов в России работают бухгалтерами, колымят делая сайты-визитки и по вечерам озверев от такой жизни фигачат вирусы на C++. Как хорошо, что я не работаю программистом :-)

Чистый C опережает C++ в два раза на мировых площадках. Но в России всё наоборот: C++ опережает C просто на порядок!

А может для С поиск производился только по латинской "C"?

     2015/01/25 14:52, Автор сайта          # 

Как хорошо, что я не работаю программистом

А кем Вы работаете?

А может для С поиск производился только по латинской «C»?

Поиск производился по разделу «ИТ» с выбором региона «вся Россия», а далее — ручной подсчёт.

     2016/05/05 14:39, utkin          # 

Года уже староваты. Обновите табличку (или добавьте новую), если имеется такая возможность.

     2016/05/05 14:52, Автор сайта          # 

Когда-то было не жаль времени, чтобы подготовить эти цифры. А сейчас хочется тратить время на другое

     2021/08/29 00:24, Бурановский дедушка          # 

Рейтинг популярности языков программирования
Место   Язык     	Баллы
===== ==== =====
1 Python 100
2 Java 95,4
3 C 94,7
4 C++ 92,4
5 JavaScript 88,1
6 С# 82,4
7 R 81,7
8 Go 77,7
9 HTML 75,4
10 Swift 70,4
11 Arduino 68,4
12 Matlab 68,3
13 PHP 68
14 Dart 67,7
15 SQL 65
16 Ruby 63,6
17 Rust 63,1
18 Assembly 62,8
19 Kotlin 58,5
20 Julia 58,3
21 Scala 55,4
22 Visual Basic 55,1
23 Shell 54,5
24 Processing 50,6
25 Fortran 45,2
26 Objective-C 44,4
27 Lua 43,3
28 Cuda 41,3
29 Verilog 40,3
30 SAS 39,4
31 Ada 38,8
32 VHDL 38,5
33 Delphi 37,8
34 Scheme 37,4
35 Perl 37,2
36 D 36,6
37 LabView 35,8
38 Haskell 35,4
39 Clojure 32,6
40 Lisp 30,4
41 Elixir 29,2
42 TCL 27,6
43 Apache Groovy 27
44 F# 22,2
45 Cobol 21,2
46 ABAP 20
47 Erlang 18,3
48 Forth 18,2
49 Prolog 16,3
50 LadderLogic 14,3
51 J 12,8
52 Ocaml 12,5
53 CoffeeScript 8,6
54 Eiffel 8,5
55 Racket 0
Источник: IEEE Spectrum

     2021/08/29 11:37, Gudleifr          # 

Я нарисовал картинку: https://i.servimg.com/u/f58/19/65/89/34/jasyki10.jpg
Все названия языков — условные, это названия целых групп.

Точка отсчета — "машинный язык" <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, немного поползли за пределы квадрата.

     2021/08/30 00:24, Автор сайта          # 

Странная у Вас схема. По идее компиляторы и интерпретаторы — это разные способы одного и того же действия: преобразования исходного кода в исполняемый и собственно исполнение. То есть это рисуется на одной оси: слева компиляторы, справа — интерпретаторы или наоборот. Где-то посредине — jit-компиляция. Это как отрицательные и положительные числа: они на одной оси. Но никак не на перпендикулярных осях.

Сами языки не накладывают каких-то ограничений на способ преобразования исходного кода и исполнения. Для тех же Си и Паскаля есть и компиляторы, и интерпретаторы. Единственное ограничение со стороны интерпретируемых языков — это наличие в них функции eval. То есть интерпретация кода на лету. Но в Clipper наличие такой функции не мешало получать файл *.exe. Видимо, компилятор встраивался в исполняемый код. Так что идея изобразить всё это на двухмерной системе координат видится неудачной.

Когда-то Япония распиарила свой проект создания машин пятого поколения. Но, несмотря на гигантские вложения, всё закончилось пшиком. Одна из причин — ставка на язык Пролог.

     2023/10/12 12:07, Вежливый Лис          # 

Я думаю, что на сайте, посвящённом языкам должны быть разделы по языкам (в смысле, по каждому из них), в которых фичи языков рассматриваются и сравниваются (а значит ещё должны быть и разделы по каждой фиче, ну, вроде того, как заделать жесткую реалтаймовость в сборщик мусора). Про языки людям интересно, вот например топик на LOR — https://www.linux.org.ru/forum/development/17376931

Разумеется, я могу наделать разделов у себя на форуме. Но там это всё-таки лишнее, так как мой форум разработке языков не посвящён.

     2023/10/12 21:42, Автор сайта          # 

С одной стороны, предложение вроде бы правильное. Хотя есть некоторые замечания.
  • Разделы должны быть не по языкам, а по фичам, потому что языков уже больше 10 000 (несколько лет назад говорили о 8 000). Думаю, что фич меньше, чем языков, да и языки во многом повторяют друг друга. Логично перечислять фичи, разжёвывать теорию и показать практические примеры из разных языков.
  • По-прежнему надо видеть разницу между языком и его реализацией. К примеру, ориентированность на реальное время — это скорее всего не из языка следует, а свойство, заложенное в компилятор. То есть существует фича «сборщик мусора», а вот как он реализован — можно привести примеры в нескольких языках, в том числе для версия для реального времени.
С другой стороны, а кто это будет делать? Например, есть такая хорошая книга (хоть и устаревшая) Р. Себесты — «Основные концепции языков программирования». Несмотря на то, что там концепции только основные, в книге 659 страниц. А какой объём она заимеет, когда вберёт в себя все? А фича — более мелкая деталь в сравнении с концепцией, значит описывать придётся ещё больше. Найдётся ли такой современный Дональд Кнут, который посвятит свою жизнь тому, чтобы всё это описать?

Каждую фичу надо изучить глубоко и не предвзято. У себя в разделе «Анализ и критика» пытаюсь это делать. Что-то выходит, что-то не очень. Например, как реализовано взаимодействие чистой и «грязной» части в языке Хаскелл — я так и не развеял туман. Кто бы это сделал, да так, чтобы «ежу было понятно»?
Ежу понятно
Хотя есть и обратные примеры.

Есть тема, которую собираюсь расширить и углубить в ближашее время. Сделаю это, держа в уме, что я работаю над языком системного программирования. Но у Андрея Бреслава или Игоря Томасова другой взгляд на применение языка, поэтому для будущего обзора было бы полезно привлечь разных авторов с разным углом зрения.

Хорошо бы найти энциклопедиста типа Дональда Кнута, но где ж его взять? Так что даже не знаю, как быть. Всякого рода форумы или телеграмм-каналы явно не подходят по формату, в них нет систематизации, что важно для научных знаний. Неплохо было бы подумать завести какую-то wiki-энциклопедию, чтобы желающие могли там что-то изложить (обещаю вносить туда свой вклад, если она появится). Даже могу подсказать: есть такая progopedia.ru, это весьма подходящая площадка для такой темы. Но там всё заглохло, регистрации нет, администратор сайта — киевлянка, и не ясно, насколько она заинтересована в развитии своего сайта и в контактах с жителями РФ. Возможно, надо будет создать с нуля что-то похожее. И даже сделать более широкий охват тем. Но это Ваша стихия — что-то планировать, так что планируйте.

Это всё, что я имею сказать в настоящее время

P.S. Прогопедия, оказывается, не работает. В вэб-архивах только осталась. Значит, о ней можно забыть.

     2023/10/12 23:09, Вежливый Лис          # 

языков уже больше 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)

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

это Ваша стихия — что-то планировать, так что планируйте

Вызов принят, только попозже, я сейчас на миссии.

     2023/10/13 16:33, Автор сайта          # 

Монадами же

Монада
Вот спасибо! А мужики и не знали.

Вы прямо проситесь стать энциклопедистом в будущей энциклопедии. Поэтому подсказываю, чего не хватает. Опишите, пожалуйста, монаду IO. Прямо по байтам. Сколько там байтов, какое у них назначение. Как передаются функциям параметры типа IO: порядок укладки их в стек. Порядок вызовов подпрограмм и возврата управления. Приведите код на ассемблере. Со всеми подробностями.

А у меня лапки

Ну так посмотрите на ёжика на картинке выше, у него тоже лапки, но, к сожалению, проблемные. Но мордочка-то умная! И это даёт надежду. Так что дайте повод надеяться и на Вас.

     2023/10/13 20:26, Вежливый Лис          # 

чего не хватает. Опишите, пожалуйста, монаду IO. Прямо по байтам. Сколько там байтов, какое у них назначение. Как передаются функциям параметры типа IO: порядок укладки их в стек. Порядок вызовов подпрограмм и возврата управления. Приведите код на ассемблере. Со всеми подробностями.

Все функции одинаково вызываются, и это ничем не отличается от разных соглашений вызовов (https://en.wikipedia.org/wiki/X86_calling_conventions)
_cdecl: ; прямой порядок расположения данных на стеке
; обратный по времени способ запихивания
; допускает переменное число параметров
; поскольку стек очищает тот, кто вызвал функцию

_stdcall: ; порядок данных — тот же самый
; но стек очищает функция
; поэтому число параметров фиксировано

_fastcall: ; аналогично stdcall, но первые параметры передаются через регистры

_pascal: ; обратный порядок данных на стеке, прямой порядок запихивания
; поэтому число параметров фиксировано, и следовательно,
; стек очищает функция
Фишка такого компилятора не в том, как он функции преобразовывает в ассемблерный код, а в том, что он знает про монады, и как проверяет остальной (проверяемый) код. Т.е. фокус на изучение вы мне не на то направляете.

     2023/10/14 23:58, Автор сайта          # 

Все функции одинаково вызываются

И при этом Вы приводите примеры вызовов в Си. А вас же просили:

Опишите, пожалуйста, монаду IO. Прямо по байтам. Сколько там байтов, какое у них назначение. Как передаются функциям параметры типа IO: порядок укладки их в стек.

А это про Хаскелл. А в Хаскелле функции каррированные (то есть вызов функции с n аргументами превращён в n вызовов по 1 аргументу). И в стек попадают не копии параметров, а их адреса — по логике для нескалярных объектов должно быть так, а как на самом деле — не нашёл информации, чтобы всё было расписано по байтам.

Зря я с Вами это обсуждаю. Ведь изначально разговор вроде был про некую энциклопедию фич языков программирования, и возражений, как вижу, не последовало. Значит, туда и надо двигаться.

     2023/11/04 22:50, Автор сайта          # 

есть такая progopedia.ru, это весьма подходящая площадка для такой темы. Но там всё заглохло, регистрации нет, администратор сайта — киевлянка, и не ясно, насколько она заинтересована в развитии своего сайта и в контактах с жителями РФ.

Прогопедия, оказывается, не работает.

Она таки работает! Оказывается, существует в доменной зоне .com: ru.progopedia.com. Who is показывает Creation Date: 2007-06-22. Видимо, изначально было зеркало, да мы не знали. Регистрация там по приглашениям, для получения приглашения надо зайти в редакторский раздел (в левой колонке, меню) и заполнить форму.

     2024/01/15 15:28, Автор сайта          # 

Так и не дождался отклика. Форму заполнил, приглашения не получил. Значит, надо вычеркнуть из своей памяти.

     2024/02/08 21:45, void          # 

С другой стороны, а кто это будет делать? Например, есть такая хорошая книга (хоть и устаревшая) Р. Себесты — «Основные концепции языков программирования». Несмотря на то, что там концепции только основные, в книге 659 страниц. А какой объём она заимеет, когда вберёт в себя все? А фича — более мелкая деталь в сравнении с концепцией, значит описывать придётся ещё больше. Найдётся ли такой современный Дональд Кнут, который посвятит свою жизнь тому, чтобы всё это описать?

Есть например, такая вот книга:

Н. Н. Непейвода, И. Н. Скопин, Основания программирования. Москва-Ижевск: Институт компьютерных исследований, 2003, 868 с., ил.

Описание: https://www.osp.ru/os/2004/02/183951

Содержимое гуглится, например: https://reallib.org/reader?file=479309&pg=1


Мне в целом нравится "полиглотный" подход авторов: когда изложение понятий и концепции происходит с нескольких сторон, то есть "изложение понятий происходит в их взаимосвязи и взаимозависимости". То есть: основные концепции, понятия, парадигмы и модели, методы программирования, технологии программирования.

Понимание методов важнее знания большого количества фактов — если понята система, как их можно вывести.

     2024/02/08 22:38, void          # 

Монада суть моноид в категории эндофункторов

Вот спасибо! А мужики и не знали.

А что не так с этим определением? Оно интуитивно понятно же. Вот смотрите, на пальцах. Есть универсальная сущность "объект в категории" и преобразования сущности, "стрелки" вида "морфизм, отображающий объект самого в себя". Например: моноид — это понятие, аналогичное алгебраическим: кольцо, поле, группа, группоид.

Берём, например, число и морфизм. 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" Там можно увидеть как получается ещё короче чем в Смоллтоке со всеми этими полиморфизмами высшего порядка, классами типов, типами классов, стрелками и объектами, монадами. Но, в отличие от того самого динамически типизированного, но медленного диспетчеризируемого Смоллтока — быстро и типобезопасно.

     2024/02/08 23:04, void          # 

А это про Хаскелл. А в Хаскелле функции каррированные (то есть вызов функции с 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 лично для меня всё-таки воспринимается как оксюморон, скорее.

     2024/02/10 13:29, Бурановский дедушка          # 

А что не так с этим определением? Оно интуитивно понятно же. Вот смотрите, на пальцах.

Объяснения совсем «не на пальцах». Среднему программисту слова «объект в категории», «моноид», «стрелки», «морфизм», «ковариантность» — это ни о чём. Про стрелки программист переспросит: а какую стрелку имеют в виду? В Юникоде много стрелок.

Раньше программированием занимались люди, у которых в дипломе была написана специальность «инженер-математик». Им преподавали высшую математику. Один из моих знакомых безуспешно пытался легализовать свой диплом в Германии, указывал им: смотрите, у меня в дипломе написано, что часов по математике мне дали больше, чем дают в вашем университете Гумбольдта. Но и такие люди часто не въезжают, что значит «моноид — это понятие, аналогичное алгебраическим: кольцо, поле, группа, группоид».

Есть такой известный блогер Олег Макаренко (он же Фриц Морген), бывший программист. Не знаю, каким он был программистом, но его единственное образование — «религиоведение». Есть знакомые программисты (надо заметить — хорошие программисты), которые вообще не имеют высшего образования. Но если бы их работа засчитывалась только тогда, когда они отчитаются о ней в терминах моноидов да группоидов, то они перестанут быть полезными обществу. Если бы у нас в профессию допускали только тех, кто оперирует такими терминами, то с работой попрощалась бы большая часть разработчиков. А страна осталась бы у разбитого корыта в плане разработки собственного ПО. Герман Греф вообще высказался, что навыки важнее знаний. Не согласен с ним, но сейчас куда меньше смотрят на диплом, всё больше на опыт работы.

     2024/02/10 15:47, Ильдар          # 

Было какое-то исследование — к чему ближе всего программирование с точки зрения работы мозга. Кажется, томографию делали. Смотрели, какие разделы головного мозга работают. Ожидали, что программирование будет иметь много общего с математикой. Но оказалось, что ближе всего к нему стоит изучение/употребление иностранных языков. Ссылку не дам (: Неудивительно, что программисты далеки от математики.

     2024/02/10 22:40, Автор сайта          # 

часто не въезжают, что значит


Определение монады

Это неважно.

Пренебрежение к «неважным» вещам приводят к эпическим провалам. Мне удалось добиться разницы в скорости программ на Си и Хаскелле в полторы тысячи раз! И это не предел. Одна из причин, почему Хаскелл так мало используется, как раз в этом и заключается. В компьютере есть всего две сущности: данные и машинный код, который этими данными пользуется. Всё остальное накладывается сверху этого. Неумение объяснить суть этих наслоений ведёт к игнорированию тяжело понимаемых теорий.

Одной из желаемых целей является простота языка: «Простота является самостоятельной ценностью». Изоляции побочных эффектов можно достичь простыми способами без привлечения терминологии, которая неизвестна людям со средним образованием. Например, все «нечистые» функции могут быть вынесены из функции и переданы ей в качестве параметра. Тогда функция, которая только что была «нечистой», превращается в условно чистую функцию. То есть её чистота зависит от условия, является ли переданная ей в качестве параметра функция чистой или нет. Это можно объяснить на двух пальцах, в отличие от «экзистенциальной квантификации». «Физик должен уметь объяснить простой уборщице, чем он тут занимается».

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

●  Изобретение очередного велосипеда?

●  Все языки эквивалентны. Но некоторые из них эквивалентнее других

●  Признаки устаревшего языка

●  Лень — двигатель прогресса

●  О наименовании проекта и языка программирования

Анализ и критика

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Новости и прочее




Последние отзывы

2024/02/24 18:10 ••• Бурановский дедушка
ЕС ЭВМ — это измена, трусость и обман?

2024/02/22 15:57 ••• Автор сайта
Русский язык и программирование

2024/02/22 14:55 ••• veector
О неправомерном доступе к памяти через указатели

2024/02/19 17:58 ••• Сорок Сороков
О русском языке в программировании

2024/02/16 16:33 ••• Клихальт
Избранные компьютерные анекдоты

2024/02/15 12:55 ••• Деньги на WWWетер
«Двухмерный» синтаксис Python

2024/02/10 22:40 ••• Автор сайта
Все языки эквивалентны. Но некоторые из них эквивалентнее других

2024/01/30 23:27 ••• Сорок сороков
О превращении кибернетики в шаманство

2024/01/23 12:04 ••• Неслучайный читатель
О многократном резервировании функций

2024/01/16 17:11 ••• Автор сайта
Некоторые «вкусности» Алгол-68

2024/01/06 16:54 ••• Ильдар
Новости и прочее

2023/12/21 18:26 ••• Автор сайта
Надёжные программы из ненадёжных компонентов

2023/12/20 18:45 ••• Автор сайта
О чистоте и нечистоте функций и языков