Влияние функционального программирования

К настоящему времени влияние функционального программирования на Erlang стало очевидным. То, что началось как добавление параллелизма к языку логики, закончилось тем, что мы удалили практически все следы Prolog из языка и добавили много известных функций из функциональных языков. К языку были добавлены функции высшего порядка и списки. Единственными оставшимися признаками наследия Prolog являются синтаксис для атомов и переменных, правила области видимости для переменных и система динамических типов.

Двоичные файлы и синтаксис битовых данных

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

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

Синтаксис бита [27] - это одна из тех незапланированных вещей, которая была добавлена ​ ​ в ответ на распространенную проблему программирования. Клак и Тони потратили много времени на реализацию различных низкоуровневых коммуникационных протоколов в Erlangе. При этом проблема упаковки и распаковки битовых полей в двоичных данных возникала снова и снова. Чтобы распаковать или упаковать такую ​ ​ структуру данных, Тони и Клаке изобрели битовый синтаксис и усовершенствовали сопоставление с шаблоном Erlang, чтобы выразить шаблоны по битовым полям.

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

< < N: 10, Flag1: 1, Flag2: 1, Flag3: 1, Status: 3> > = B

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

Mnesia ETS таблицы и базы данных

При разработке крупномасштабных телекоммуникационных приложений вскоре стало очевидно, что «чистый» подход к хранению данных не может удовлетворить требования крупного проекта и что необходима какая-то база данных в реальном времени. Эта реализация привела к созданию СУБД под названием Mnesia (Первоначальное имя было Amnesia, пока старший менеджер Ericsson не заметил его. «Невозможно назвать Amnesia», - сказал он, - «имя должно быть изменено»), и поэтому мы отбросили «a») [24, 25, 21]. Эта работа была начата Klacke Butsoon с участием Ганса Нильссона, Tö rbjö rn T ̈ ornkvist, Hå kan Matssonand Tony Rogvall. Mnesia имела компоненты как высокого, так и низкого уровня. На самом высоком уровне абстракции был новый язык запросов, названный Mnemosyne (разработанный Хансом Нильссоном), а на самом низком уровне был набор примитивов в Erlangе, с помощью которых Mnesia могла быть написана. Мнезия удовлетворяла следующим требованиям (из [21]):

1. Быстрый ключ / значение поиска.

2. Сложные запросы не в реальном времени, в основном для эксплуатации и обслуживания.

3. Распределенные данные за счет распределенных приложений.

4. Высокая отказоустойчивость.

5. Динамическая реконфигурация.

6. Сложные объекты.

Чтобы внедрить Mnesia в Erlang, нужно было разработать еще один модуль Erlang. Это был модуль Erlang ets, сокращение от E rlang t erm storage. ets предоставил низкоуровневое деструктивное хранилище на основе расширяемых хеш-таблиц. Хотя он выглядит так, как если бы он был реализован в Erlang (т.е. это модуль Erlang), большая часть его реализации содержится в реализации виртуальной машины Erlang.

Вывод типа программ Erlang

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

Первая попытка создания системы типов была вызвана инициативой Фила Уодлера. Однажды Фил позвонил мне и объявил, что а) Erlangу нужна система типов, б) он написал небольшой прототип системы типов и в) у него был годичный отпуск, и он собирался написать систему типов для Erlang и «мы были заинтересованы? » Ответ - «Да».

Фил Уодлер и Саймон Марлоу работали над системой типов более года, и результаты были опубликованы в [20]. Результаты проекта были несколько разочаровывающими. Для начала, только подмножество языка было проверяемым по типу, главное упущение - отсутствие типов процессов и межпроцессных сообщений проверки типов. Хотя их система типов никогда не была запущена в производство, она привела к записи для типов, которая все еще используется сегодня для неофициального аннотирования типов. Несколько других проектов проверки типов Erlang также не дали результатов, которые можно было бы ввести в производство. Только в появлении Dialyzer ( DI screpancy Ana LYZ er of ER lang программы) [18] стал возможен реалистичный анализ типов программ Erlang. Диализатор возник как побочный эффект упомянутого ранее проекта HiPE. Чтобы эффективно скомпилировать Erlang, выполняется анализ типов программ на Erlang. Если у вас есть точная информация о типе функции, может быть выдан специализированный код для компиляции этой функции, в противном случае генерируется общий код. Команда HiPE пришла к выводу, что полная информация обо всех типах всех переменных во всех операторах программы Erlang не нужна, и что любые определенные утверждения о типах, даже очень небольшого подраздела программы, предоставляют полезную информацию, которая может направлять компилятор в создание более эффективного кода. Dialyzer не пытается определить все типы в программе, но любые типы, которые он выводит, гарантированно будут правильными, и, в частности, любые найденные ошибки гарантированно будут ошибками. Dialyzer теперь регулярно используется для проверки больших объемов производственного кода.

Часть IV: 1998 - 2001 гг. Проблемы развития - бурные годы

1998 год был захватывающим годом, когда произошли следующие события:

· Первое демо GPRS (General Packet Radio Service), разработанное на Erlang, было продемонстрировано на Всемирном конгрессе GSM в феврале и на CeBIT в марте.

· В феврале Erlang был запрещен в Ericsson Radio Systems.

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

· В декабре был выпущен открытый исходный код Erlang.

· В декабре большая часть группы, которая создала Erlang, ушла из Ericsson и основала новую компанию под названием Bluetail AB.

 

Успешные проекты

В 1998 году был продемонстрирован первый прототип системы GPRS и был анонсирован Ericsson AXD301. Обе эти системы были написаны на смеси языков, но основным языком управления в обеих системах был Erlang.

Самая большая система, построенная в Erlangе, была AXD301. На момент написания этой системы было 2, 6 миллиона строк кода Erlang. Успех этого проекта показывает, что Erlang подходит для крупномасштабных промышленных программных проектов. Система не только большая по объему кода, она также очень надежна и работает в режиме реального времени. Изменения кода в системе должны выполняться без остановки системы. В доступном пространстве сложно адекватно описать эту систему, поэтому я приведу лишь краткое описание некоторых характеристик.

AXD301 написан с использованием распределенного Erlang. Он работает в кластере с использованием пар процессоров и может масштабироваться до 16 пар процессоров. Каждая пара «самодостаточна», что означает, что если один процессор в паре выходит из строя, другой вступает в работу. Механизмы захвата и управления вызовами все запрограммированы в Erlang. Данные конфигурации и данные управления вызовами хранятся в базе данных Mnesia, к которой можно получить доступ из любого узла, и реплицируются на нескольких узлах. Отдельные узлы могут быть выведены из эксплуатации для ремонта, а дополнительные узлы могут быть добавлены без прерывания обслуживания.

Программное обеспечение для системы программируется с использованием поведений из библиотек OTP. На самом высоком уровне абстракции находится ряд так называемых «деревьев наблюдения» - работа узла в дереве наблюдения заключается в том, чтобы отслеживать его дочерние элементы и перезапускать их в случае сбоя. Узлы в дереве решений являются либо деревьями контроля, либо примитивным поведением OTP. Примитивное поведение используется для моделирования клиент-серверов, регистраторов событий и конечных машин. В анализе AXD, о котором сообщалось в [7], AXD использовал 20 деревьев наблюдения, 122 модели клиент-сервер, 36 регистраторов событий и 10 машин конечного состояния.

Все это было запрограммировано командой из 60 программистов. Подавляющее большинство из этих программистов имели промышленный опыт и не имели предварительных знаний о функциональных или параллельных языках программирования. Большинству из них преподавал Erlang автор и его коллеги. В течение этого проекта группа OTP активно поддерживала проект и предоставила инструментальную поддержку, где это необходимо. Многие внутренние инструменты были разработаны для поддержки проекта. Примеры включают компилятор ASN.1 и встроенную поддержку SNMP в Mnesia.

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

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

AXD301 [8] имел потрясающий успех. По состоянию на 2001 год в нем было 1, 13 миллиона строк кода Erlang, содержащихся в 2248 модулях [7]. Если мы консервативно оценим, что одна строка Erlang будет соответствовать, скажем, пяти строкам C, это соответствует системе C с более чем шестью миллионами строк кода. Что касается надежности, AXD301 обладает наблюдаемой надежностью в девять девяток [7] - и четырехкратное увеличение производительности наблюдалось в процессе разработки [31].

⇐ Предыдущая123456Следующая ⇒

Поделиться: