Я писал ранее о том, что меня наняли для написания нового языка программирования dist-sys для Wayfair в Берлине, и о своих мыслях о том, что это будет значить для языка BEAM.

Но до того, как я начал работать в Wayfair, я написал свои мысли о том, как мы могли бы создать язык dist-sys, ориентированный на LLVM, и отправил его своему будущему боссу [машет рукой юристам Wayfair].

Главный вопрос: что нам строить?

Но, выбрав этот вопрос, возникает вопрос, как нам его построить? какие принципы должны лежать в его основе? Прежде чем создавать что-то вроде языка программирования, необходимого для разработки процесса проектирования, вам нужно спланировать сокращение объема необходимой работы и ее устранение, а также подумать о цепочке инструментов и как подойти к этому.

Прочитав историю сначала Erlang, а затем Erlang / OTP, мы убедились в важности извлеченных уроков, понимания того, какие языки программирования люди используют для создания, прежде чем создавать или расширять новые. За свою карьеру я извлек много уроков, извлеченных из гиперчислов, моего неудачного стартапа, из самого Erlang / OTP, из новой мультипарадигмальной экосистемы BEAM и построения распределенных систем в Basho.

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

Эта статья завершается некоторыми предлагаемыми экспериментами:
• многоцелевой автомат на основе лучей
• реализация теоретико-множественных работ на существующем языке APL-y
• реализация регулярных выражений Rust как мини-интегрированный язык семейства Rust

Caveat Lector: все это все еще немного похоже на BEAM, но это потому, что я долгое время работаю в BEAMer - рабочее предположение состоит в том, что основным языком будет Rust.

Что нам строить?

Стоит хорошенько разобраться, что мы предлагаем делать. Вначале программы кодировались аппаратно - машина Бэббиджа, жаккардовый ткацкий станок, бомба Тьюринга. Мы понимаем цену этого - переключение бомбы Тьюринга на новую военно-морскую машину Enigma во время битвы за Атлантику потребовало 8 месяцев для аппаратной компиляции.

Алан Тьюринг и Томми Флауэрс выполнили первые два больших раздела:

  • разделение программы на оборудование и программное обеспечение
  • разделение программного обеспечения на данные и программу

Там ситуация оставалась до конца 1960-х годов. Инженеры IBM систематизировали свою работу и вытащили все общие компоненты, которые они повторно использовали в проектах, в набор общих библиотек, и так родились операционные системы.

Операционные системы стали большим улучшением, потому что ваше неписаное программное обеспечение обладало определенными возможностями, а именно:

  • был запущен в общей многопользовательской среде
  • может разговаривать с постоянным хранилищем
  • мог поговорить с сетью
  • мог разговаривать со стандартными механизмами ввода и вывода, бумажной лентой, перфокартами, телетайпом и более поздними мониторами

С появлением Erlang / OTP (а различия между Erlang и Erlang / OTP мы рассмотрим позже) мы получаем дополнительный раздел.

Исходя из предпосылки, что надежная система должна работать как минимум на 2 компьютерах, мы можем рассматривать Erlang / OTP как набор библиотек, которые работают на 1 или более компьютерах, чтобы обеспечить надежную программную систему:

Это дает нам следующий раздел:

Кластерная система предоставляет нашему незаписанному программному обеспечению набор характерных свойств:

  • он может работать на более чем одном компьютере
  • он выполнит аварийное переключение при наличии аппаратной ошибки

Он также обеспечивает выполнение ряда вещей на языке программирования:

  • во время записи неизвестно, где конкретный программный компонент будет выполняться во время выполнения

У нас есть несколько вопросов, на которые мы должны ответить:

  • строим ли мы еще одну кластерную систему 2-го поколения, что-то параллельное Erlang / OTP, которое улучшит ее, чтобы мы могли извлечь из нее уроки и применить их?
  • стремимся ли мы к следующему разделу - языку программирования для создания приложений, которые работают в двух или более кластерах / центрах обработки данных и обеспечивают постоянное обслуживание в случае сбоя кластера? (здесь есть какая-то странная середина осведомленности о стойках, которая является кластерной системой + 1 -ish)
  • каков контекст безопасности? будет ли эта система работать на серверах внутри периметра безопасности или их можно будет развернуть в общедоступном Интернете?

Как только мы поймем, что можем составить исчерпывающий список свойств, которыми должно обладать наше неписаное программное обеспечение.

Если это следующий раздел, то новый язык / парадигма должен быть доступен при различных сбоях в работе: отказ машины, потеря центра обработки данных, системный отказ в центре обработки данных (трехфазное питание, сетевое соединение, Кондиционер и охлаждение, ИБП, стоечная инфраструктура и т. Д. И т. Д.)

Это будет означать, что наше ненаписанное программное обеспечение, как правило, должно быть:

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

быть частью хорошо настроенного и оперативно управляемого кластера

Как нам его построить? - стратегия

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

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

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

Уроки выучены

В этом разделе будут собраны некоторые уроки, которые, как мне кажется, я усвоил в прошлой жизни, относящиеся к этому проекту.

Уроки Hypernumbers I - важность стиля

Hypernumbers - один из моих неудачных стартапов - электронная таблица нового поколения в Интернете. В этих видеороликах можно увидеть, как это отличается:

В его основе лежал рекурсивный язык программирования на основе выражений со встроенным языком запросов:

  • Z-запросы

Главный урок Hypernumbers - не очевидный технический.

Мы сознательно работали над тем, чтобы сделать Интернет программируемым, но также совместимым с Excel '95, поэтому = sum (A1, A2, A3), за исключением того, что A1 - это краткий URL-адрес http : //mysite.com/some/spreadsheet/page/a1. Каждая ячейка имела свой собственный URL-адрес, и обновление ячейки включало отправку выражения по этому URL-адресу. Это выражение может работать с локальными или удаленными URL-адресами.

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

Оказывается, вы вообще не программируете на Fortran, Erlang, C или Excel ’97.

Вы пишете Fortran в стиле Fortran, Erlang в стиле Erlang.

Написав Hypernumbers, нам пришлось научиться программировать Hypernumbers в стиле Hypernumbers как отдельную задачу.

Настоящий урок состоит в том, как ретроспективно взглянуть на языки программирования и определить множество, которое они содержат:

  • Серверы Erlang - запрограммированы на Erlang в функциональном стиле Erlang
  • Тесты Erlang - запрограммированы на Erlang в декларативном стиле Erlang.
  • Регулярные выражения Erlang - запрограммированные на языке, основанном на встроенном парсере - митохондриальный остаток изначального супа программирования, из которого мы, о, совсем недавно, обходились

Чтобы быть полезными, мы традиционно создали языки программирования, которые «достаточно велики», чтобы выполнять всю работу - и это привело к разрастанию синтаксиса и сложности - чтобы охватить все стили . Прекрасным примером является Perl, который никогда не встречал никакого синтаксического сахара, чего не было бы - правильный правильный диабет 3 типа в языке.

Определяя стили, которые нам необходимы, и создавая языки программирования, которые являются краткими и привязанными к определенному стилю, мы можем сократить объем работы, которую нам нужно сделать.

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

Уроки Hypernumbers II - необходимое ядро ​​языка мало

Когда мы создавали Hypernumbers, мы предполагали, что некоторая процентная совместимость с Excel «95» будет минимальным продуктом.

4 года спустя на конференции European Spreadsheet Risk Group Conference мы увидели результаты первого крупного аудита электронных таблиц в дикой природе:

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

(да, именно поэтому Hypernumbers потерпели неудачу, недостаточное количество экспериментов с клиентами и вовлеченности, слишком много технической лапши.)

Уроки C - и основанные на нем языки

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

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

Это расширилось от простого написания времени выполнения языка на C до повторного использования элементов цепочки инструментов, компилятора, LLVM и т. Д. И т. Д.

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

Схематично это можно показать:

Не будет преувеличением сказать, что Json спроектирован как промежуточный язык передачи данных с наименьшим общим показателем для переноса структур данных PHP на Javascript (и наоборот). Попытка сопоставить их соответствующие таблицы истинности (y) друг с другом побудила бы, нет, конечно, заставила бы многих программистов выпить.

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

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

(Это верно для языков на BEAM - синтаксисы Erlang и Elixir перекрываются - с частичным исключением (очень полезного) оператора конвейера - и синтаксис на самом деле не дает оснований использовать один вместо другого - инструменты с другой стороны …)

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

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

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

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

Уроки Erlang / OTP I - модель актера

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

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

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

Одновременное программирование многих компьютеров навязывает нам модель передачи сообщений / актора, но все же необходимо дать определение области действия актора.

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

Большие серверы теперь поставляются с горстью ядер, каждое с горстью потоков выполнения.

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

Уроки Erlang / OTP II - надзор, дизайн, итерация и т. Д.

Это процесс проектирования для Erlang / OTP:

Из этого можно извлечь три реальных урока:

  • мы должны принять итеративный процесс - начать работу над языком - создать в нем что-то, проанализировать и систематизировать этот материал / эти шаблоны и передать их обратно в язык
  • мы должны рассмотреть вопрос о том, чтобы сделать деревья и стратегии надзора примитивом времени выполнения, а не языка - другими словами, вывести надзор из языковой области (чтобы уменьшить размер языка)
  • Поскольку Networked Erlang был более поздним развитием, разделение канала управления и канала выполнения оставлено на усмотрение разработчиков системы (и на практике большинство из них не создают панель управления). Это означает, что сообщения процесса отправляются через сеть Erlang, а не через HTTP и т.д., и это сериализуется через точку сети - для больших двоичных файлов вы получаете блокировку в строке управления со всеми вытекающими из этого проблемами. Мы, безусловно, должны запечь разделение контроля и исполнения в

Уроки Erlang / OTP III - конфигурация декларативна

В старые времена, когда начинали писать приложение на Erlang (то есть до создания арматуры), вы часто начинали с написания стартовой функции, которая выглядела примерно так:

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

Все мы знаем и ненавидим ужасных установщиков-установщиков других языков. выбранный вами язык.

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

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

Для генерации конфигурации необходимо использовать последовательности, поэтому 99-й сервер имеет для этого 99-е значение.

В языке должны быть диагностические функции, генерируемые как часть процесса компиляции, аналогичные my_module: module_info (exports) в Erlang - те, которые генерируют описания развертываемой системы.

Уроки мультипарадигмальной экосистемы BEAM I - сладкое взаимодействие

Erlang имеет синтаксис Prolog-y, а недавние разработки в области BEAM привели к росту Elixir с более знакомым синтаксисом Algol-y и LFE / Joxa, которые оба являются LISP-y.

Платформа обеспечивает сходство между базовой структурой всех этих языков. В начале находится модуль. Давайте посмотрим на базовый модуль на трех основных языках BEAM.

Модуль Elixir - в синтаксисе algol-y, с которым знакомо большинство людей:

А теперь в Erlang - языке с синтаксисом прологии, который вызывает загадочную, но настоящую ненависть:

И, наконец, это не скобки вашего отца, это шепотливый LFE-модуль - LFE расшифровывается как Lisp Flavored Erlang natch:

При внимательном рассмотрении этих трех разновидностей языков BEAM становится очевидным, что они очень тесно связаны - мы видим, что основное различие заключается в синтаксических элементах - основная структура одинакова. Это сходство связано с тем, что все они скомпилированы в один и тот же набор инструкций BEAM в файлах .beam с одинаковой внутренней структурой - и все они одинаково выполняются на виртуальной машине Erlang в разных операционных системах.

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

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

Мы можем сопоставить общие элементы:

По сути, все, начиная с общих структур данных и ниже, одинаково и согласованно выражается в Erlang AST или различных эквивалентных представлениях (Elixir AST, Core Erlang и т. Д.).

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

А теперь в Эрланге:

Интероперация - cludgyAF из-за небольших синтаксических изменений:

  • как называются функции
  • тот факт, что в Elixir есть пространство имен для имен модулей, а в Erlang нет
  • двоичные в Erlang называются строками в Elixir, а строки в Erlang называются charlists и их синтаксические изменения между языками
  • атом в Erlang - это atom, но : atom в Elixir

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

  • объявления типов
  • вызов функции

При просмотре вызова функции на языке X вы не должны знать, написан ли вызываемый модуль в X, Y или Z.

Уроки мультипарадигмальной экосистемы BEAM II - инструменты

Elixir был разработан с нуля для использования базовой инфраструктуры Erlang, но при этом исправляет различные пробелы в инструментах. Особо следует отметить hex - систему управления пакетами, которая открыта для пакетов Erlang как равных пакетам Elixir.

Основной набор инструментов сборки также упрощает добавление зависимостей Erlang в приложения Elixir.

Обратное, но это не так - включить приложение Elixir в приложение на Erlang невозможно. Инструменты его ни в малейшей степени не поддерживают. Единственное практическое решение - создать новое пустое приложение Elixir и добавить приложение Erlang и соответствующие приложения Elixir в качестве взаимозависимостей.

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

Уроки мультипарадигмальной экосистемы BEAM III - вспомогательные языки
Я написал несколько длинных сообщений о дополнительных языках для BEAM, по одному на:

На первом языке - скомпилированный исходный код будет создавать серию модулей, реализующих поведение в Erlang, то есть определенные наборы функций обратного вызова, составляющие контракт. Пользователь мог бы запрограммировать эти обратные вызовы на языке BEAM по своему выбору (Erlang, Elixir или LFE / Joxa).

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

Эти два языка не будут стремиться охватить весь след среды программирования - они будут не языками общего назначения, а вспомогательными языками. Они расширили бы возможности базовой платформы и делегировали бы большие объемы работы существующим языкам, Erlang, Elixir или LFE. Если мы посмотрим на матрицу возможностей, мы можем получить такое впечатление:

Для языка dist-sys мы бы написали библиотеки на Erlang для обработки причинно-следственных связей, консенсуса, кластеризации, репликации, хеширования / маршрутизации и развертывания, а язык программирования мог бы эффективно настраивать и создавать эти библиотеки для создания согласованной системы. Фактически основная часть функциональности будет реализована в Erlang, Elixir или LFE как обратные вызовы - с интерфейсами, определенными новым дизайном языка.

APL - это около 80 килобайт C ++ или примерно 26 килобайт Erlang. Многие из них случайны:

  • возможность записи на экран или в файл
  • загрузка библиотеки
  • REPL
  • и другое вязание

Сделав язык APL-y простым библиотечным языком - бесполезным на практике, если он не вызывается программой на Erlang или Elixir, - этот целевой размер может быть значительно уменьшен. На практике большинство из 80 или около того функций в стандартном APL являются вариантами на map, reduce и filter с различными переданными им функциями.

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

Маловероятно, что для первой итерации потребуется полный набор из 80 операторов APL, что сократит объем работы.

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

Чтобы понять, что я имею в виду под сверхфокусированным синтаксисом, стоит взглянуть на необработанный APL:

(Есть язык J - родственник APL - который использует символы ascii только в своем синтаксисе - но он все равно выглядит странно и незнакомо, лолол)

Это настолько далеко от Erlang, Elixir или LFE, насколько это можно вообразить. Идея написать деревья супервизии с этим синтаксисом также заставляет мои глаза кровоточить. Я пишу это как человек, который всего за 4 часа чтения руководства APL находит APL ужасающе красивым и соблазнительным.

Уроки Басё

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

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

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

Как нам его построить? - тактика

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

Черновой вариант архитектуры может выглядеть так:

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

Caveat Lector: имена Stato, Freako и Dato являются заполнителями ;-), но в целом процесс взятия корней англосаксонских слов из 6–8 букв и наклеивания на них псевдоромантических окончаний существительных вполне хороший и дешевый способ создания множества связанных слов, которые можно купить как .com и для которых доступен дескриптор Twitter. На самом деле именование должно быть первоклассным процессом с дизайнером и маркетологами, full bhuna. Дурацкий выбор имени является обычным явлением в ИТ-индустрии - FFS называет язык «Go» - разве AF был мышлением Google (чертова поисковая машина!)?

Предлагаемые эксперименты

Есть 3 эксперимента, которые напрашиваются для изучения этого пути проектирования.

Эксперимент I - язык распределенного конечного автомата на BEAM
Предложение

Напишите язык распределенного конечного автомата на BEAM с процессами Erlang, представляющими распределенных участников в кластере с несколькими машинами, в соответствии с проектной документацией. Внутреннее представление будет Liffey, как описано в этом документе - обратные вызовы будут фактическим поведением FSM.

Обоснование

Мы знаем BEAM и его конечные автоматы, и у нас есть достаточно спецификации для обучения.

Обучение

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

Эксперимент II. Любит ли APL-y теоретико-множественный язык?
Предложение

Попробуйте реализовать некоторые теоретико-множественные компоненты в APL согласно статье.

Обоснование

Язык APL-y по соображениям BEAM возник в результате примерно 4 часов чтения руководства по APL и 4 часов попыток повторно реализовать проблему кода Basho в онлайн-репозитории APL.

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

Обучение

Стоит ли вообще рассматривать синтаксис APL и теоретико-множественный язык? Или, например, в тот день он просто засветился?

Эксперимент III - крошечный вспомогательный язык для Rust
Proposal

Чтобы написать регулярные выражения - встроенный в ur язык - как собственный синтаксический язык, чтобы исследовать проблемное пространство гладкого взаимодействия с общими инструментами.

Обоснование

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

Обучение

Все обучение будет посвящено инструментам и взаимодействию:

  • как встроить этот новый язык в развертывание Rust
  • повторное использование модульного и системного тестирования
  • наличие генераторов вывода компилятора для нагрузочного и модельного тестирования
  • наличие наборов тестов вывода компилятора, которые формально завершены
  • компоновщики и привязка объектов с разных языков к исполняемым файлам

Также можно было бы запустить мягкий запуск сообщества / инициативы с открытым исходным кодом.

Если вам это нравится, подпишитесь на меня в Twitter @gordonguthrie или, еще лучше, наймите меня.