| ClipArtMag Science Blog |

Free Cliparts

Почему Я Программирую В Erlang

Перевод статьи - Why I Program In Erlang

Автор - Evan Miller

Источник оригинальной статьи:

http://www.evanmiller.org/why-i-program-in-erlang.html

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

Тем не менее, в течение почти пяти лет я провел большой кусок своего свободного времени программирования в Erlang; на данный момент я провел более тысячи часов с языком. Я использовал язык, чтобы написать, в грубом хронологическом порядке, CSV парсер (не смейтесь, я сказал хронологическом порядке), шаблон компилятора, объектно-реляционного отображения, богатый-анализатор текста, изменение размера изображения, язык препроцессора, веб-фреймворк, и распределенной очереди Сообщений. Ниже приведены мои впечатления о языке по сравнению с другими языками, которые я использовал профессионально (C, Java, Perl, PHP, Ruby, Objective-C и JavaScript).

Хорошие новости о Erlang можно суммировать на этом: Erlang кульминация 25 лет правильно решений конструкции в языке и платформе. Всякий раз, когда я задавался вопросом о том, как что-то в Erlang работает, я никогда не был разочарован в ответ. Я почти всегда оставляю впечатление, что дизайнеры сделали "правильную вещь". Я полагаю, это в отличие от java, который делает педантичный вещь, на Perl, который делает то угловатые вещи, Ruby, который имеет два независимых реализаций неправильная вещь, и C, который ничего не делает.

Возьмите сбор мусора. Когда пришло время собирать мусор на других языках, вся система должна остановиться, пока работает сборщик мусора. Этот подход идеально подходит, если ваша компьютерная программа должна запускаться один раз, писать некоторые результаты, а затем выйти. Но в длительных приложениях, таких как настольные, мобильные или серверные программы, эта стратегия приводит к иногда замороженным UI и медленным временам отклика. Программы Erlang, с другой стороны, могут иметь тысячи независимых куч, которые собираются отдельно; таким образом, со временем распределяется штраф за производительность сборки мусора, и поэтому длительное приложение не будет загадочно отвечать время от времени во время работы сборщика мусора.

Или взять конкатенацию строк. Если вы откроете реализацию конкатенации строк в Perl, Ruby или JavaScript, вы обязательно найдете инструкцию if, realloc и memcpy. То есть, когда вы объединяете две строки, первая строка становится местом для второй, а затем вторая копируется в первую. Этот подход работал в течение десятилетий и является "очевидным". Подход Erlang неочевиден и, я считаю, верен. В обычном случае Erlang не использует непрерывный фрагмент памяти для представления последовательности байтов. Вместо этого он называется “список I/O” - вложенный список несмежных фрагментов памяти. Результатом является то, что объединение двух строк (списки I/O) занимает O(1) время в Erlang, по сравнению O(N) время в других языках. Именно поэтому рендеринга шаблона в Ruby, Python и т. д. медленно, но очень быстро в Erlang.

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

Я упомянул, что рефакторинг кода Erlang - это боль. К счастью, в моем опыте редко возникает необходимость рефакторинга кода Erlang таким же образом, как объектно-ориентированный код нуждается в рефакторинге время от времени. В Erlang каждая функция передает всю необходимую информацию, и вы получаете предупреждение компилятора, если он передал любую информацию, в которой он не нуждается. В некотором смысле, рефакторинг интегрирован в развитие; это не отдельный вид деятельности, требующий обильного покрытия теста и нескольких горшков кофе. Рефакторинг Java или Objective-C код обычно становится необходимым, потому что слишком много методов экземпляра были добавлены к классу, и разработчик должен потратить время на выяснение, какие методы требуют, какие переменные экземпляра и как лучше всего сократить каретку пополам. Это просто не забота в функциональном программировании; двигать функцию к различному модулю требует очень маленький рук-отжимать и фактически никакого усилия. "Рефакторинг" в Erlang обычно состоит из разбиения больших функций на меньшие функции. Существует не так много умственных усилий; однако из-за синтаксических особенностей Erlang может быть утомительным преобразование анонимных функций в именованные функции. Возможно, умная среда IDE однажды устранит эту скуку.

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

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

И поэтому мы приходим к плохим новостям о Erlang: преимущества языка снова загружены. То есть, большинство преимуществ языка можно оценить только после нескольких лет с другими языками, а затем несколько лет с Erlang. Это, конечно, не язык для начинающих. Синтаксис странен для программистов, родом из C диаспоры. Функциональное программирование жесткое, и Erlang не кладет сахар на таблетку. Графические наборы инструментов примитивны, и нет заполняющих кода компьютерных игр, таких как находятся во вводных курсах Java. Чтение любого нетривиального кода Erlang требует твердого понимания рекурсии, своего рода абстрактного мышления, которое многие люди находят трудным.

Erlang также не хватает библиотек по сравнению с другими языками; по моему опыту, для любой данной задачи есть ноль, один или не более двух библиотек Erlang, доступных для работы. Я, возможно, один, когда я говорю это, но мне на самом деле нравится тот факт, что есть не так много библиотек Erlang доступны. Если мне нужно что-то сделать, у меня есть оправдание, чтобы сделать это сам, и я часто делаю открытия, которые я бы не сделал иначе. Звучит глупо, но это правда. Я могу чувствовать себя продуктивно, потому что я делаю то, что еще никто не сделал, и по пути у меня есть свобода пробовать новые подходы и делать реальные инновации. Я узнал больше в процессе разработки библиотек Erlang, чем когда-либо научился сшивать код Ruby или C других людей. Я программирую в Erlang исключительно для того, чтобы решать проблемы и делиться своими открытиями в хорошо спроектированных приложениях.

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

Для программиста, который хочет писать быстрые программы, используя Erlang - виды программ, которые запускают, записывают некоторый вывод и выходят - есть надежда на несколько фронтов. Компилятор собственного кода доступен, и в соответствии с результатами численных показателей, это делает Erlang программы быстрее, чем Ruby, Perl и РНР, хотя и медленнее, чем Java и javascript. Речь идет о just-in-time native-code компиляторе, который мог бы обеспечить дальнейшие улучшения времени выполнения, почерпнув информацию из самого выполнения кода и сделав соответствующие оптимизации. Наконец, смельчаки могут написать вычислительноемких код на C через NIF, с важными оговорками, что код на С будет блокировать Erlang scheduler (параллелизм возможности потенциально отрицая Erlang), и тот параллельный код C очень трудно писать.

Мой собственный выбор для написания быстрых программ в Erlang - это альтернативная технология, которая дает все преимущества кода C без ущерба для целостности времени выполнения Erlang. Это OpenCL, C-подобный язык, представленный Apple в 2008 году. Как и Erlang, OpenCL легко использует преимущества всех процессорных ядер на данной машине; в отличие от Erlang, программы OpenCL очень быстро. На самом деле, программ ОpenСl являются, как правило, быстрее, чем программы на C, в качестве программы ОpenСl может воспользоваться векторный потенциал процессора таким образом, что, как правило, требуется ручная настройка ассемблерный код. Программы OpenCL могут быть скомпилированы и выполнены непосредственно из кода Erlang; на мой взгляд, это идеальная технология для выполнения вычислительно интенсивных задач (то есть выполнения этих внутренних циклов) внутри более крупной программы Erlang.

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

Изменения

10/30/2012 - незначительные разъяснения и исправления