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

Следующие 7000 языков программирования

Роберт Чатли, Аластер Дональдсон, Факультет вычислительной техники, Имперский колледж, Лондон, Великобритания
Алан Майкрофт, Компьютерная лаборатория, Кембриджский университет, Кембридж, Великобритания alan.mycroft@cl.cam.ac.uk

Ведение

Основополагающий документ Ландина «Следующие 700 языков программирования» рассматривал языки программирования до 1966 года и рассуждал о следующих 700. Полвека спустя мы приводим языки программирования к дарвинистскому «древу жизни» и исследуем языки, их особенности (гены) и эволюцию языков с точки зрения «выживания наиболее приспособленных». Мы исследуем этот тезис, исследуя, как различные языки развивались в прошлом, а затем рассмотрим расхождение между языками, эмпирически используемыми в 2017 году, и языковыми особенностями, которые можно было бы ожидать, если бы языки 1960-х развивались оптимально, чтобы заполнить свои ниши программирования.

Это приводит к характеристике трех расхождений, или «слонов в комнате», где фактическое текущее использование языка или предоставление функций отличается от того, что может предложить эволюция. Мы заключаем, размышляя о будущей языковой эволюции.

1. Почему языки программирования такие, какие они есть, и куда они идут?

В 1966 году ACM опубликовал заметную статью Питера Ландина «Следующие 700 языков программирования» [22]. Семь лет спустя родились «Заметки лекций в области компьютерных наук» (LNCS) Спрингера (вместе с Уилфредом Брауэром в качестве редактора первого тома [5]). Впечатляюще, главы из этого первого тома охватывали почти все темы, которые мы сейчас рассматриваем как основную компьютерную науку: от компьютерного оборудования и операционных систем до обработки на естественном языке и от сложности до языков программирования. Пятьдесят лет спустя, по случаю 10000-го тома LNCS, кажется уместным поразмышлять о том, где мы находимся, и сделать некоторые прогнозы — и это эссе посвящено языкам программирования и их развитию.

Стоит рассмотреть эпиграф статьи Ландина, цитату из проспекта Американской математической ассоциации за июль 1965 года: «... сегодня... 1700 специальных языков программирования, используемых для «общения» в более чем 700 прикладных областях». В настоящее время получить эквивалентную цифру может быть гораздо сложнее – поэтому наше название «следующие 7000 языков» чисто риторическое.

С одной стороны, опрос Конвея и Уайта 2010 года [http://www.dataists.com/2010/12/ranking-the-popularity-of-programminglangauges/[sic]] (вдохновляющий постоянные опросы RedMonk) обнаружил только 56 языков, используемых в проектах GitHub или появляющихся как теги StackOverflow. Это дает оценку количества языков, «активно используемых», но, в частности, исключает языки в крупных корпоративных проектах (не на GitHub), особенно там, где есть хорошая местная поддержка или другие сдерживающие факторы для решения проблем программирования, не требующие использовать общедоступное. С другой стороны, языки программирования продолжают появляться с огромной скоростью; если мы посчитаем каждый предложенный язык, возможно, включая языки конфигурации и исчисления исследовательской работы, число языков теперь должно быть шестизначным.

Основным направлением работы Ландина было утверждение, что следующие 700 языков после 1966 года должны основываться на семействе языков, которое он назвал ISWIM и которое характеризуется:

  • а) вложением с помощью отступа [Основными языками, использующими отступы, являются Python и Haskell] (возможно, для противодействия основанной на тогдашней тенденции типа «все утверждения начинаются в столбце 7» (Fortran);
  • б) гибкие механизмы определения объема, основанные на λ-исчислении, с возможностью рассматривать функции как первоклассные значения и
  • в) императивные функции, включая операторы присваивания и управления потоком.

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

В то время как легкая лексическая область {...} теперь часто используется для вложения вместо принятия пункта (a), интересно отметить, что область видимости и контроль (б) и (в) в последнее время были основными направлениями для улучшений в Java 8 и 9 (например, лямбда-выражения, потоки, CompletableFutures и реактивное программирование).

Ландин утверждал, что ISWIM должен быть семейством языков, параметризованным его «примитивами» (предположительно, чтобы позволить его использовать в нескольких областях, специфичных для приложений). В настоящее время специфичное для данной области использование, как правило, достигается путем введения абстракций или импорта библиотек, а не путем корректировки самого основного языка. Действительно, кажется, существует сильная корреляция между количеством и доступностью библиотек для языка и его популярностью.

Цель этой статьи состоит из трех частей:

  • изучить тенденции в языковом дизайне (как в прошлом, настоящем, так и в будущем),
  • доказать, что дарвинистская эволюция по пригодности применима как к языкам, так и к формам жизни (включая причины, по которым некоторые менее подходящие языки могут сохраняться в течение длительных периодов времени) и
  • выявить некоторые экологические нагрузки (и, возможно, даже недостаточно занятые ниши), которые эволюция языка могла бы, и мы утверждаем, должна бы занять.
Наше изучение ниш на языках программирования не позволяет нам постулировать универсальный основной язык, соответствующий ISWIM Ландена.

1.1 Дарвиновская эволюция и языки программирования

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

Эта аналогия позволяет нам глубже задуматься об эволюции языка. В устойчивом состоянии (подумайте о своем любимом клочке земли — будь то сельская местность, кустарник или пустыня) ежегодное изменение среды обитания мало. Это, несмотря на то, что различные растения или приверженцы языков программирования распространяют семена — буквально или семена инакомыслия — и пытаются заселить соседние ниши. Однако вещи обычно не являются действительно устойчивым состоянием, и инвазивные виды растений могут быть более приспособлены к экологической нише и вытеснять нынешних жителей.

В контексте языка программирования инвазивные языки могут возникать в университетах, в которых участвуют выпускники, которые спокойно применяют устойчивые методы программирования в существующих проектах, пока они не станут достаточно взрослыми, чтобы начать новый проект [Представьте себе дискуссии, состоявшиеся в Facebook, о том, как размещать типы в одном миллионе строк PHP и, следовательно, в языке программирования Hack] — или реорганизовать старый — используя свое образование. Инвазивные языки также могут поступать из промышленности — сколько ученых предсказало бы, что к 2016 году, согласно RedMonk, JavaScript будет самым популярным языком на GitHub, а также будет иметь наибольшее количество тегов в StackOverflow? Недавнее эмпирическое исследование показывает, что измерение популярности через объем кода в общедоступных репозиториях GitHub может вводить в заблуждение из-за дублирования кода, и что код JavaScript демонстрирует высокую степень дублирования [24]. Тем не менее, остается очевидным, что JavaScript является одним из наиболее широко используемых языков сегодня.

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

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

Забавно, что другие факторы, которые поощряют принятие языка (например, библиотеки, инструменты и т.д.), имеют растительную аналогию в виде симбионтов — перенос (или создание) широкого спектра библиотек для языка улучшает его перспективы.

Академическая литература в целом объединяет языки программирования в такие парадигмы, как императивная, объектно-ориентированная и декларативная; мы можем расширить нашу аналогию, рассматривая парадигмы как аналогичные основным характеристикам растений, причем языки определенных парадигм особенно хорошо адаптированы к определенным нишам; например, ксерофиты хорошо адаптированы к пустыням и функциональны.

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

Точно так же эволюция языка может позволить языкам приобретать аспекты множества парадигм (например, Ada является главным императивным языком, несмотря на наличие объектно-ориентированных возможностей, а C# имеет определенный уровень функциональных возможностей, усиленный более поздней библиотекой LINQ для запроса данных).

Между прочим, идея экосистемы языка программирования со многими нишами обеспечивает академическое обоснование того, почему прошлые попытки создать «универсальный язык программирования» (начиная с PL/I) часто оказывались бесплодными: язык, способный к выражению нескольких парадигм программирования рискует стать по своей сути сложным и, следовательно, трудным для изучения и эффективного использования.

Основной причиной этой сложности является сложность рассуждений о взаимодействии функций. Современный язык, который с самого начала тщательно комбинировал несколько парадигм, — это Scala. Однако благодаря получаемой гибкости может быть много разных стилистических подходов к решению конкретной проблемы программирования в Scala, используя разные элементы языка. Дизайнер языка Мартин Одерски описывает Scala как «... немного хамелеона... в зависимости от того, на какой фрагмент кода вы смотрите, Scala может выглядеть очень просто или очень сложно» [http://www.scala-lang.org/old/node/8610].

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

Мы обсудим некоторые из этих идей более конкретно в разд. 3, но суммируя, основные внешнее («изменение климата») давление на эволюцию языка в том виде, в каком мы их видим в настоящее время:

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

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

Мы рассматриваем эволюцию как «отбор наиболее приспособленных» после мутации (внедрение новых генов и т.д.). Хотя механизм мутации (человеческий дизайн в языках программирования и случайная мутация в организмах) отличается, это не влияет на аспект отбора.

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

Мы обсудим аспекты пригодности позже (например, простоту программирования).

1.2. Структура статьи

Мы начнем с более подробного изучения истории (раздел 2), обсудим факторы, влияющие на эволюцию языка программирования (раздел 3), и рассмотрим наиболее популярные языки программирования на момент написания, согласно RedMonk, IEEE Spectrum и Рейтинги TIOBE (раздел 4). Наш анализ выявляет трех «слонов в комнате» — языковых тенденций, которые скорее вступают в противоречие с «выживанием наиболее приспособленных» точек зрения, — которые мы обсудим более подробно (раздел 5). Мы заключаем, размышляя о будущей языковой эволюции (раздел 6).



Перевод: Д.Ю.Караваев. 14.11.2019

Опубликовано: 2019.11.25, последняя правка: 2019.11.25    21:58

ОценитеОценки посетителей
   ██████ 1 (12.5%)
   ████████████████ 3 (37.5%)
   ██████ 1 (12.5%)
   ████████████████ 3 (37.5%)

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

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

Авторизация

Регистрация

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

Карта сайта


Содержание

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

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

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

Компилятор

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

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

●  О превращении кибернетики в шаманство

●  Про лебедей, раков и щук

●  О замысле и воплощении

●  О русском ассемблере

●  Арифметика синтаксиса-3

●  Концепция владения в Rust на примерах

●●  Концепция владения в Rust на примерах, часть 2

●●  Концепция владения в Rust на примерах, часть 3

●  Суть побочных эффектов в чисто функциональных языках

●  О неулучшаемой архитектуре процессоров

●  Двадцать тысяч строк кода, которые потрясут мир?

●  Почему владение/заимствование в Rust такое сложное?

●  Масштабируемые архитектуры программ

●  О создании языков

●●  Джоэл Спольски о функциональном программировании

●  Почему Хаскелл так мало используется в отрасли?

●  Программирование исчезнет. Будет дрессировка нейронных сетей

●  О глупости «программирования на естественном языке»

●  Десятка худших фич C#

●  Бесплатный софт в мышеловке

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

●  ЕС ЭВМ — это измена, трусость и обман?

●  Русской операционной системой должна стать ReactOS

●  Почему обречён язык Форт

●  Программирование без программистов — это медицина без врачей

●  Электроника без электронщиков

●  Программисты-профессионалы и программирующие инженеры

●  Статьи Дмитрия Караваева

●●  Идеальный транслятор

●●  В защиту PL/1

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

●●  Опыт самостоятельного развития средства программирования в РКК «Энергия»

●●  О реализации метода оптимизации при компиляции

●●  О реализации метода распределения регистров при компиляции

●●  О распределении памяти при выполнении теста Кнута

●●  Опыты со стеком или «чемпионат по выполнению теста Кнута»

●●  О размещении переменных в стеке

●●  Сколько проходов должно быть у транслятора?

●●  Чтение лексем

●●  Экстракоды при синтезе программ

●●  Об исключенных командах или за что «списали» инструкцию INTO?

●●  Типы в инженерных задачах

●●  Непрерывное компилирование

●●  Об одной реализации специализированных операторов ввода-вывода

●●  Особенности реализации структурной обработки исключений в Win64

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

●●  Формула расчета точности для умножения

●●  Права доступа к переменным

●●  Заметки о выходе из функции без значения и зеркальности get и put

●●  Модификация исполняемого кода как способ реализации массивов с изменяемыми границами

●●  Ошибка при отсутствии выполняемых действий

●●  О PL/1 и почему в нём не зарезервированы ключевые слова

●●  Не поминайте всуе PL/1

●●  Скорость в попугаях

●●  Крах операции «Инкогнито»

●●  Предопределённый результат

●●  Поддержка профилирования кода программы на низком уровне

●●  К вопросу о парадигмах

●  Следующие 7000 языков программирования

●●  Что нового с 1966 года?

●●  Наблюдаемая эволюция языка программирования

●●  Ряд важных языков в 2017 году

●●  Слоны в комнате

●●  Следующие 7000 языков программирования: заключение

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

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




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

2024/12/07 20:54 ••• Клихальт
Переключатель

2024/12/06 18:44 ••• Анкнав
Русский язык и программирование

2024/12/01 00:00 ••• alextretyak
Продолжение цикла и выход из него

2024/11/29 23:08 ••• Вежливый Лис
О русском ассемблере

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

2024/11/25 18:31 ••• Деньги на WWWетер
Ресурсы, посвящённые созданию языков программирования и компиляторов

2024/11/12 20:24 ••• Вежливый Лис
Правила языка: строки, комментарии

2024/11/12 13:10 ••• Вежливый Лис
Новости и прочее

2024/11/12 00:32 ••• Автор сайта
Оценка надёжности функции с несколькими реализациями

2024/11/06 02:50 ••• Иван
Энтузиасты-разработчики компиляторов и их проекты

2024/11/05 23:51 ••• Борис К.
Изменение приоритетов операций

2024/11/05 23:38 ••• Борис К.
Шестнадцатиричные и двоичные константы

2024/11/01 12:11 ••• ИванАс
Русской операционной системой должна стать ReactOS