Записки программиста

Темы выпуска: сколько форкнуть Xen’ов, Erlang-девочки и теория категорий, системы типов и сиподобная лапша, а также ответы на вопросы слушателей. Предыдущие выпуски: четырнадцатый, тринадцатый, двенадцатый, одиннадцатый.

Слушать онлайн:
http://eaxcast.podfm.ru/_eaxcast/15/

Скачать файл:
http://eaxcast.podfm.ru/_eaxcast/15/file/podfm_eaxcast__eaxcast_208.mp3

Шоу нотес:

• Список книг от Максима
• Статья и слайды про TLA+ в Amazon;

Голоса выпуска: Максим @5HT Сохацкий, Валерий @sum3rman Мелешкин, Иван @gliush Глушков, Александр @afiskon Алексеев

Фоновая музыка: The Panets — Winter Beats (Big Power Mix)

 

А: Всем привет, вы слушаете EaxCast, второй сезон, восьмой выпуск. Это продолжение интервью с Максимом Сохацким. Сережа Елин нас покинул, ему на смену пришел Ваня gluish Глушков, я правильно произнес?

И: Нет, gliush.

А: Глиуш. Надо будет заботать. Мы продолжаем, и я так понял, Валера продолжает свою серию хитрых вопросов.

В: Ну, в общем, я собственно, что хотел спросить? Максим закончил на том, что Erlang on Xen – в принципе, этот контейнер можно запускать на практически каждого пользователя, это быстро и довольно экономно. И у меня возник такой вопрос, а чем это принципиально лучше запуска lxc контейнера?

А: У меня другой вопрос, я сразу встряну. Чем это принципиально лучше создания процесса ерлангового?

М: Самый экономный вариант – это создание ерланг-процесса, но, если речь идет о какой-то сущности, которую мы можем остановить и потом полностью запустить и сосредоточить какие-то вычисления от имени какого-то конкретного юзера в виде виртуальной машины, то мы можем легко при неактивности этого пользователя держать эти вычисления засуспенженными. Что касается lxc контейнера, то очевидно, что слишком много слоев и стеков в линуксе для обеспечения… Ну допустим, мы разрабатываем какое-то приложение поисковое и нам нужно где-то хранить индексы. Что мы делаем? Мы в Key-Value storage’е создаем какие-то таблицы, какие-то записи и делаем B-Tree хранилища для того, чтобы хранить наши индексы в нашей поисковой системе. А что такое Key-Value storagе? А Key-Value storagе – это тоже какая-то штука, которая хранит в B-Tree все индексы внутри какого-то файла на файловой системе.

А что такое файловая система? Файловая система – это тоже какое-то B-Tree хранилище, которое хранит индексы этих файловых дескрипторов. Понимаете? Получается у нас на ровном месте три уровня B-Tree, три уровня баз данных, три уровня файловых систем, и непонятно почему это все вообще так произошло. Очевидно, что какая-то была допущена ошибка при конструировании промышленных систем в 60-х годах с появлением UNIX-а. И мы хотим эту ошибку исправить. Очевидно, что имея чистый Xen контейнер, мы можем построить минимально необходимое обеспечение хранения данных. Почему не lxc. LXC – это очень удобная штука для прототипирования деплоя, для деплоя legacy unix приложений. Это очень удобно, используя docker задеплоить что-то, куда-то в виде одного файла, запаковать это вместе с файловой системой. В docker’е, как вы знаете, оно версионируется, в отличие от чистого lxc контейнера. Т.е. там есть версионированная файловая система – очень удобная штука. Я советую, кто еще не использовал докер, обязательно посмотрите, эта штука очень перспективная. В будущем предполагается написание плагинов различных. В том числе Вова Кирилов работает с docker-командой над тем, чтобы использовать docker-интерфейс для создания xen образов.

А: Я знаю, кто из нас сейчас без проблем сочинит какой-нибудь вопрос по докеру.

М: Давайте.

А: Да, Вань?

И: Вообще, я хотел вернуться немного назад. В docker мы очень весело перешли, я готов про него потом поспрашивать.

В: Дело в то, что. Да, да.

И: Давай я вопрос задам, потом ты все это вместе резюмируешь. Получается, что Xen – это, в принципе, чуть похуже, чем Erlang процессы? Они будут запускаться чуть помедленней и Erlang машина сама по себе, если она уже работает, она быстрей создаст процесс и быстрей обработает входящий запрос.

М: Конечно.

И: А какой смысл тогда генирить? Не легче иметь одну большую машину, которая будет хорошо работать с кучей ядер и легко обрабатывать все входящие запросы?

М: Гранулярность масштабирования, т.е. для того, чтобы в том месте, где нужно срезать пики, у вас получится. Вот, когда происходит всплеск нагрузки, вы можете очень точно нарезать мощность через каждые 20 Мб и каждые 50 мс. А в случае с каким-то незапланированным пиком, вам делать какие-то запросы, чтобы выделить мне машину либо мне диапазон машин – 10 машин. Я вижу, что у меня сервис растет, нагрузка растет, пожалуйста, подготовьте мне 10 машин и разворачивайте полностью эти 10 машин. Т.е. там поднимается Linux, поднимаются все сервисы, все это коннектится в кластер. Это все много, это не 50 мс. Мы сокращаем гранулярность масштабирования кластеров до минимума.

И: И это очень полезно для облачных сервисов вида то, что мы в Amazon-е имеем или в Google облаке. Т.е. фактически мы пришли к тому, что облачные структуры нам уничтожают все преимущества Erlang потому, что мы фактически уходим от больших машин, мы переходим к маленьким машинкам, которые быстренько создаются налету. Нам уже нет необходимости работать с несколькими ядрами.

М: Да. Erlang on Xen поэтому не поддерживает мультикорность потому, что она ему не нужна. Ему не нужно SMP, потому, что на Xen сервере мы создаем в среднем ну я не знаю… Citrix Xen сервер, он поддерживает 1000 нод на машину, т.е. это 1000 инстансов на одном компьютере, одновременно работающих. Это хорошо.

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

М: Нет, вы не привязываетесь к use case, допустим, facebook-а, где там 3 млрд. пользователей. Тут бывают разные приложения, понимаете? И те приолжения, где эти цифры сойдутся с количеством пользователей, количеством виртуальных, количеством процессов, это будет очень хорошо играть. Нужно просто задействовать и разработать такие use case. Просто, недостаточно потрачено времени на разработку и детальную проработку этих сценариев использования этой технологии. Т.е. сама технология, очевидно, показывает, что этого показателя, как запуск виртуальной машины за 50 мс можно что-то состричь. И, вот, просто нужно это до конца проработать.

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

М: Возможно такие разговоры и будут, но дело в том, что я представляю компанию Cloudozer только, как своих друзей. Понимаете? Я не официальный представитель компании Cloudozer, и не официальный представитель компании Docker. Надо понимать четко, что я просто делаю web-сайтики на N2O, а говорим мы про создание нового поколения cloud. Я польщен, что мы подаем такие вопросы и это очень приятно, я думаю, будет аудитории это послушать.

А: Давайте немножко сменим тему потому, что вопросу Erlang on Xen было уделено немало времени. У меня, вот, другой вопрос, более прозаичный. Максим, если я не ошибаюсь, от тебя была инициатива под названием Erlang Girls.

М: Да, есть такая инициатива. У нас очень много, есть девочек из Киева, которые посещают Functional Programming, в основном, это благодаря харизме и сексуальности Владимира Кирилова.

А: Т.е. оно все еще работает, как это сейчас выглядит?

М: Сейчас это выглядит так, что, допустим, в группе Erlang Girls на Facebook девочки говорят «Мы давно не виделись, хотим вас послушать. Приходите с Вовой, посидим в парке, вы нам расскажите, чем вы занимаетесь» и мы девочкам рассказываем. А сегодня мы типа зарелизили такую штуку на Erlang, а Вова на Haskell такую штуку написал и рассказывает про изоморфизм Карри-Ховарда или еще какие-то штуки. Ну, что-то такое, что они обычно не услышат на своих митингах, на Bullshit-Bingo митингах.

А: А это девушки занимаются pet project-ами?

М: У девушек есть pet project-ы и они работают все в каких-то компаниях в Киеве. Некоторые девочки пишут на Python, на Ruby, на Coco под iOS. В общем, очень разные.

А: И большой сейчас размер группы?

М: Нет, 5 человек. Они вообще не хотели называться Erlang, они хотели Lambda Girls называться.

А: Но мне кажется это разумно. Я, кстати, тоже расстроен, почему обязательно Erlang Girls? Может быть, им там Clojure интересна или, вот, Haskell ты говоришь.

М: Интересно, потому, что много девочек посещают наш Kiev-Fprog.

А: По-моему, Вань ты пытался задать вопрос.

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

М: Ну, конечно же, интересно. Если объяснять не очень сложным языком, то это очень понятные вещи. Просто люди интересуются и хотят саморазвиваться. Почему бы не помочь людям поднять свой уровень профессиональный? Я считаю, что это очень хорошо и эта реклама того чтоб занимались функциональным программированием. «Девушки в Киеве занимаются функциональным программированием. Почему вы не занимаетесь функциональным программированием? Непонятно!» — вот такой месседж для людей должен быть.

И: Ну, это замечательно, я прям аплодирую. Молодцы.

В: А девочки сами собрались или вы их как-то собирали?

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

А: Кстати, Вань, я правильно понял, мы, вот, в конце первой часть интервью упомянули functional programming moscow teach meet-up, надо же такое придумать. Я правильно понял, тебя ведь тоже туда позвали?

И: Да, меня туда позвали.

А: Ты еще думаешь?

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

А: Я так понял, как мне объяснили, это будет 50 рубистов, которые заинтересованы в ФП, ну и видимо, в разной степени, кто-то в курсе, кто-то не очень.

М: А, понятно, т.е. надо больше информировать, скорей объяснять, почему это так круто. Как раз, вот, ваши girls отлично подойдут сюда, если приедут и все расскажут этим крутым рубистам.

А: Про теорию категорий.

И: Да, да, и они будут просто в шоке.

М: Мы тренируем.

А: Кстати, Максим.

В: Тренированные категориальные девушки.

А: Категоричные. Максим, я так понимаю, ты был замечен в группе в ЖЖ, которая категория теорий и вообще ты…

М: Я автор группы этой.

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

М: Да, можно попробовать рассказать. Оно в целом очень сильно затрагивает тот алфавит, который мы используем для обучения хаскелю и функциональным языкам программирования. Что такое, допустим, типизированная программа? Типизированная программа представляет собой категорию. Что такое категория? Представьте себе, что есть какой-то граф с точками и со стрелками, и вот каждая точка на этом графе – это какой-то тип данных, допустим, там: int, string, или что-то там. Допустим, мы пишем программу на Pascal и у нас есть какие-то типы элементарные или, там, на Erlang, и вот эти все типы – это какие-то точки, а функции между этими точками – это стрелки в этом графе. Каждая типизированная программа представлена в виде вот такого графа. Это достаточно просто всем себе представить.

Если у нас есть какие-то, допустим, два графа, первый же вопрос, который люди задают, а что если у нас параметр – не одна переменная, а несколько. Это будет означать просто, что вам нужно построить композицию этих функций и вам нужно сцепить эту цепочку и это, как бы, будет выглядеть, так графически каррирование на этом графе. Что, если у вас, допустим, есть два графа? У вас идет та программа и тут вторая программа, и вы делаете какое-то преобразование одной программы, которая постоянно ведет из одного графа в другую программу. Это называется функтор. Для него нужно соблюсти какое-то правило, чтобы все стрелки, которые делают преобразование одной программы в другую… Ну, по сути, это DSL, функтор – это вот такие структуры, которые переводят стрелки, функции одной программы в функции другой программы. При этом типы должны частично совпадать. Дальше, если, допустим, таксономию этих типов, что же там внутри находится, то мы должны очень просто это объяснить. Абстрактные типы данных в виде там, как в языке C определяется структурой union. Что мы можем конструировать типы в первом приближении из двух элементарных функций, это, допустим, плюс и умножение. Если мы конструируем типы с помощью умножения, то мы просто строим векторы или, так называемые, кортежи. Если мы используем сумму, то мы ставим операцию «или», т.е. в этом месте может быть или этот тип, или этот тип.

Вот, допустим, все динамические типизированные языки, в том числе и Erlang, они представлены в виде манул, все типы представлены в виде одного типа. Т.е. это языки с одним типом, но этот тип имеет структуру – это сумма все элементарных типов: int, bool, double, list. Это все как бы варианты, либо это, либо это, либо это, может быть переменной. Вот это все такие моноиды. Потом можно рассказывать, что, допустим, не типизированные лямбда исчисления – это просто где есть вот такие, есть один тип и на него не накладываются никакие ограничения. Если есть типы, то очевидно, что должна быть какая-то система конструирования типов, а чтобы конструировать типы, минимум нужны две функции: плюс и умножение для того, чтобы строить кортежи и union, но также можно добавить и другие функции.

Фактически, мы выходим на лямбда вычисления второго уровня – лямбда большое (?), когда мы можем писать программы, писать функции не только на значения каких-то типов, но и на самих типах. Т.е. мы можем писать, допустим, функцию, которая конструирует дерево. Дерево – это либо узел этого дерева, либо правая или левая часть или nil. Т.е. это всё выражение будет выражено через сумму и умножение. Но кроме суммы и умножения вы можете использовать другие функции, и этот набор выводит вас в лямбда исчисление над типами – в лямбда большое. Ну, вот, в целом я затронул все аспекты функционального программирования, которое можно представить себе в виде графов, в виде теории категорий. Можно сказать, что теория категорий математически отвечает на все вопросы природы лямбда исчисления, как выглядит структура этой категории, как выражается объект натуральных чисел, как выражаются элементарные операции моноидальные, это все очень строго описано и это нужно человеку, который занимается программированием на Haskell.

Чтобы понимать, как это работает, он должен в этом тоже разбираться. Можно, конечно, писать, не умея доказывать теоремы, но, так или иначе, в Haskell это все, как бы, наружу. Вы все равно используете эту терминологию, этот алфавит и этот язык функторов, аппликативных функторов, монад – это всё термины из теории категорий.

А: Ну, слушай, в первом приближении оно довольно несложно звучит, а почему тогда все так боятся этой теории категорий и считает, что это сложно, непонятно?

В: Нет хорошего изложения нигде.

М: Нет хорошего изложения и, кроме того, все изложения, которые пытаются всё упростить, я же тут наговорил, на самом деле, очень много глупостей потому, что это всё в высшей степени неточно и неадекватно. Это, как бы, математический язык, а математический язык нельзя упростить до человеческого. Т.е., если вы будете упрощать, вы будете совершать ошибки, это будет все неграмотно. Понимаете? Поэтому нету такого понятия – неформальная теория категорий либо неформальная математика. Все-таки теория категорий – это математика и нужно, как минимум, знать кванторы и делать это всё содержательным. Если вы просто играете словами, то вы просто берете Haskell и играетесь там себе, пишите программы, вы тоже это все делаете. Но теория категорий – это все-таки математический аппарат, который, если вам хочется знать, почему все так, почему нельзя комбинировать то, а там можно делать композицию, вы должны все-таки посмотреть, почему оно все так происходит в математике.

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

В: А Пирса читал?

М: Ну, конечно. У меня же есть все эти подборки книжек. Если кто-то хочет почитать все книжки, которые я читал по этой теме, они все публично выставлены, я дам вам ссылку.

И: Ну, вот, я пока не очень понял, получается, что теория категорий нужна интересующимся, которые пытаются глубже проникнуть в суть? А, фактически, если у нас есть два человека – один хорошо знает Haskell и знает теорию категорий, второй хорошо знает Haskell, но не знает теорию категорий. Какие будут преимущества у первого?

В: А он теоремы может доказывать.

М: Он лучше понимает, у него больше понимание будет у первого.

В: Ну, тут дело, мне кажется, больше не столько в понимании, я не знаю, возможно, сейчас холиворную тему подниму, есть очень классное приложение всеобщее, вот такого матана применительно к современным системам. Современные системы они адски сложные, большинство из них. Даже тот, клон facebook для постинга котят – это на самом деле сложная система, сложная в смысле того, что там дофига движущихся частей и, как правило, хочется понимать, что она работает правильно. Может быть для котят это не так критично, но если мы пишем, например, что-то вроде того же самого Riak, нам скорей всего хочется понимать, что наша база данных работает правильно. Возникает сразу два момента, во-первых, нам нужно уметь сформулировать, что такое правильно, а, во-вторых, нам нужно уметь проверить, что это действительно правильно. И, вот, тут без формализмов уже не обойтись, а там где формализм – там математический язык и в случае некоторых формализмов там же и теория категорий.

А: Максим, ты с этим согласен или нет?

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

В: Тут, на самом деле, еще Amazon недавно постили whitepaper, где они рассказали, как они успешно внедрили у себя TLA+. Это такая темпоральная логика, авторства Лесли Лэмпорта.

А: Ссылку в show notes. Не забудь.

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

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

И: Все понятно. Вопрос тогда следующий. Если не теория категорий, тогда что? Что читать и что узнавать? Ты, в частности, какие книжки сейчас читаешь и какие книжки ты вообще рекомендуешь читать?

М: По работе я сейчас читаю пэйперы по pattern matching compilation. Что читать людям, которые хотят заниматься функциональным программированием? Ну, я уже дал ссылку, там есть всё, там есть основные статьи по всем функциональным языкам программирования. Конечно, нужно уметь читать, сейчас время такое в функциональном мире, что если ты не можешь читать статьи про ML Милнера, все должны понимать, как выглядит программа на ML и что там значит сигнатуры, функторы и все эти штуки. ML – это классика и все должны понимать и разбираться, чтобы читать хотя бы программы какие-то, алгоритмы. Haskell – это потолок, все равно все рано или поздно, если нужно, что-то серьезное написать, все придут в Haskell. Вот Haskell сейчас очень хорошо выглядит, и я очень удивлен скоростью, какой достигает результирующая программа. Это уже, конечно, запредельно.

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

И: Но это же неудобно.

М: Просто язык, который мы разрабатываем, он направлен на embedded, на sdn свитчи и там не нужно описывать протоколы типов.

И: Если сравнивать Haskell и OCaml, тот же самый, то OCaml мне не нравится за то, что они с типами, со спецификациями, явные спецификации типов, как-то, ну, очень неудобно работают, а то и не работают совсем.

М: У OCaml просто система типов помягче, чем у Scala и Haskell, поэтому там все так выглядит довольно громоздко. Там нету kind-notion и вы не можете type-holes driven programmming делать на OCaml. Потому, что очень старый этот engine, а вот на Scala и на Haskell…

И: Вы к этому же самому приходите, что вы запрещаете пользователям описывать типы.

В: К тому же ты говоришь, что не хочется протоколы описывать, как может не хотеться протоколы писать типами?

М: Все равно ж будут сайд-эффекты потому, что будут send message в другие процессы. И у вас есть какой-то receive. В этом receive, ну в Erlang, как вы конструируете программы, как вы пишите протоколы? Вся ваша композиция протоколов будет представлять несколько ресивов, т.е. в нескольких местах. Допустим, есть три функции, в каждой из них есть ресив. В этом ресиве есть список того, что – список ног, список leg-ов, где вы получаете какие-то сообщения. Эти сообщения могут быть какого-то типа, да? Когда вы делаете унификацию типов, вы объединяете все типы в leg каждого ресива, у вас получается три union, правильно? Вот, наша система вам покажет, что существует в системе три типа и вот это ваш протокол. Он сам вам построит эти типы, вы не должны ему указывать. Вы пишите программу, как обычный какой-то сишный программист, вы не знаете ни про системы типов, ничего. И мы вам построим и покажем оптимальный, допустим, если у вас были какие-то реврайты, мы вам покажем, что у вас есть дупликация где-то в типах, вы это все неправильно сделали, либо тут вот так вот, какие-то рекомендации сможем вам дать по вашей программе.

И: Чем-то напоминает Cloud Haskell.

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

М: В том то и дело, что у вас же реакция на эту ногу в ресиве. У вас это какая-то функция, которая принимает какой-то тип. Т.е. хороший type inferer должен разрулить, в конце концов.

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

М: Две ноги типа одинаковые или что?

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

М: Мы только что рассказали про union ног, это типизация только вот входящего, в спецификации, потока.

В: Да.

М: А можно еще специализировать send message’ы, в правой стороне – функции могут посылать куда-то сообщения.

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

А: Я думаю Валер, ты просто мечтаешь о Haskell, но еще не осознаешь этого.

В: Возможно.

А: Я просто вижу, что диалог идет менее продуктивно, чем хотелось бы. Поэтому я предлагаю переключить немножко тему. Максим, у тебя есть опыт программирования, как на C#, так и на Erlang.

М: Да.

А: С таким богатым опытом ты ведь наверняка можешь без проблем сказать для каких задач Erlang хорошо подходит, для каких он совсем не подходит и где, например, ты бы не стал использовать Erlang, но стал бы использовать C# или может другой язык?

М: В общем, я бы конечно, писал бы на C# только от большого горя. Наверно когда, допустим, нужно было бы слезть с героина или сесть на героин. Т.е. я предлагаю вообще забыть про сиподобную лапшу, все эти C#, и какие бы там они хорошие не были эти Go и Rust, про это все надо забыть. Писать нужно на, чтобы хоть как-то оно было похоже на ML язык. Erlang – это, конечно, самый слабый из всех существующих, он, вообще, даже не ML подобный.

В: Rust же похож на ML.

М: Rust? Да ну.

А: Ну, он немножко.

М: Rust – сиподобная лапша.

А: А Scala? Сорри, Scala это?

М: Scala – это прекрасный язык.

А: ML подобный?

М: Мне очень нравится Scala.

А: Ок. Нет, я просто разобраться, что ML подобное, а что сишная лапша? Извини, продолжай.

М: F#, Scala для энтерпрайз программистов есть только две точки, как они могут обезопасить и сделать свое пребывание в бодишопах более комфортным и хоть как-то провести время с пользой там. Это, значит, для .NET программиста, он должен писать на F#, а Java программисты должны писать на Scala.

В: А Clojure?

М: А на Clojure вам не разрешат писать в бодишопах, как бы вы не пытались. Для этого вам нужно уходить из бодишопов, ставать там каким-то CTO в какой-то компании и там развивать это направление.

А: Уходить в Machine Zone. К Никите :)

М: Да, уходить в Machine Zone.

Вам не разрешат в банках на Lisp писать.

Я очень люблю Clojure. Весь наш стек, web-стек, он построен в том числе на… Я наблюдал за тем, что существует в Clojure мире, я пытался все это сделать по кодам, мне очень нравится, как в Clojure выглядит все маленьким, вы можете композить как хотите, соединять очень маленькие библиотеки. Я таким же образом пытался сделать декомпозицию всего нитрогена и выбрать те штуки, которые основные и которые можно заменить. Поэтому я даже попробовал посмотреть, как выглядела бы компиляция из Erlang в JavaScript, чтобы повторить вот эту универсальность кода на стороне сервера и клиента, попробовать компилировать react приложения, которые написаны в Erlang синтаксисе. У меня есть такие эксперименты, ну, я, в конце концов, этот JavaScript компилятор использую для спецификации JavaScript протоколов на Erlang, чтобы на Erlang проверять их типизацию.

И: Хорошо, вот мы коснулись Scala, мы коснулись энтерпрайза.

М: Scala, Haskell, Clojure, Erlang — вот языки, все остальное можно даже не смотреть, а просто знать, что вот такое есть.

В: ATS же еще.

М: Нет, есть много разных языков, есть Agda, вы можете попробовать что-то подоказывать на Agda, на Coq.

В: Нет, ну, Agda не такая производительная, а ATS якобы быстрее сишечки бывает.

М: Haskell тоже вот быстрее сишечки бывает.

В: Но, у ATS еще нет garbage collection.

М: Garbage collection – интересная штука, про нее тоже можно долго разговаривать, как вы, допустим, сейчас будете делать garbage collection. Это все очень интересная тема, но времени не хватит про это все говорить. Очень хотелось бы. Я, вот, хотел в следующий выпуск fprog’а сделать: собрать все чуваков, которые пишут под web на официальных языках, там: Соловьева, Тонского и написать какие-то статьи, как функциональщики пишут котов для интернета, как хранят котов в интернете. Но, что-то так не получилось, все были заняты, Тонский уходил с «Эха» в Machine Zone, Соловьев занят на работе, в общем непонятно. Выпуск не состоялся, тут еще эта война. Я думаю, что у меня появилась другая идея, и я бы хотел собрать каких-то чуваков, которые компиляторы пишут. Но я, к сожалению, не знаю никого, кто пишет компиляторы. Ключников занимается совершенно другим, т.е. он пишет статьи на тему суперкомпиляции и зависимых типов, но это немножко не то. Я бы хотел просто, чтобы люди понимали, как создавать иные языки, ML подобные языки, как современные языки конструируются. Все знают, все используют pattern matching, во всех языка это сейчас must have в любом языке. Вот как вот, допустим, написать pattern matching компилятор или как написать простой inferer типов? Вот такие вот вещи, думаю, что это было бы познавательно и интересно.

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

А: Я присоединяюсь и призываю.

В: А fprog.ru вообще жив? Я что-то очень давно не видел даже твитов в twitter-е fprog.

М: Ну, вот, я говорил, что в прошлом году должна была выйти в декабре статья по web. Я там должен был написать про свой компилятор Shen, Тонский должен был про Clojure что-то написать, про react должна была быть статья от Соловьева, но все так немножко притормозилось. Я думаю, что можно реанимировать этот процесс.

А: А нужен ли журнал? Может быть, публиковать у себя в жежешечках статьи, он там попадут на планету и нормально.

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

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

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

А: Я понял, а нас просто поджимает время, давай перейдем к вопросам слушателей, тут их штуки 4-5, вот, буквально в двух предложениях ответ. Ок? Вопрос формулируется так, есть ли смысл в Elixir и прочих языках под BEAM?

М: Конечно, это очень интересная тема, дело в том, что система языковой поддержки в Erlang исключительно красива и функциональна. Вот, например, в Java и в .Net у вас есть единый байт-код и единая система типов и компиляторы, которые генерируют байт-код. Т.е. представьте себе, вот, я пишу компилятор для .NET написал один, написал там три интерпретатора и компилятора для .Net. Вот, я пишу компилятор, мне нужно генерировать байт-код, т.е. мне нужно для каждого нового языка, кроме лексера и парсера, писать еще и компилятор, делать самому оптимизации, а, как вы знаете, любой компилятор – минимум пять проходов, а то и десять. В Erlang их вообще 25. И зачем постоянно делать оптимизацию для каждого языка, для каждого проекта компилятора?

Поэтому в Erlang за счет того, что очень проработан весь pipeline компилятора, в нем есть несколько уровней языковых. Один из самых низких уровней, который все слышали – это Erlang core. Erlang core – это такой ерланговый DSL для представления структуры программы ерланговской в виде элементарных синтаксических конструкций. Но в Erlang core нет рекордов потому, что Erlang core – это уже скомпилированная программа. А есть на уровень выше, допустим, Erlang AST. В Erlang AST есть упоминание о Erlang record, т.е. там вы можете делать макросы, инклюды, которые у вас есть, директивы компилятора. Они все тоже в Erlang AST включаются. И там уже, как бы, сразу вы даете, вот моя программа, вот допустим, там есть какой-то свитч или pattern matching.

Если вы даете Erlang-у Erlang AST, он его сам скомпилирует до Erlang core и прооптимизирует. И, вот, Elixir построен точно таким образом. Elixir не генерирует байт-код, он генерирует Erlang AST из эликсировской программы и дает на компиляцию компилятору Erlang-а. Компилятор Erlang уже производит сам все необходимые оптимизации. И вот такой путь позволяет очень быстро делать прототипы языков для языковой среды Erlang-а. Если вы пишите, вам достаточно просто написать какой-то лексер и парсер, и вы сразу сможете сгенерировать AST. Т.е., по сути, это будет просто какой-то препроцессор DSL из вашего языка в Erlang AST. А дальше все оптимизации, pattern matching компиляции, все эти штуки, рекорды, все это сделает за вас компилятор Erlang-а. Это намного меньше сил нужно тратить разработчику компиляторов языков для платформы Erlang, допустим, люди тратят при написании компилятора для .Net и для Java. И в этом вот и крутость, это очень круто! И я поощряю развитие любых синтаксисов под Erlang, возможно кто-то возьмет и напишет сиподобную лапшу-синтаксис для Erlang, почему бы нет?

Я бы это приветствовал и хочу сказать, что это очень просто сделать. Если у вас уже есть где-то в ваших наработках лексер и парсер языка C, вы сможете за два, буквально, вечера, если вы сами написали это всё, и вы за два вечера сможете сделать генерацию Erlang AST и получить си-подобный компилятор под Erlang. В этом плане toolchain Erlang-а для построения языков и компиляторов очень удобный. Это все, что я могу сказать про использование других языков в Erlang.

А: Вопрос, как я его понимаю, тут его просто скидывали в google docs, видимо, вопрос о том, на чем ты пишешь, в каком редакторе, под чем сидишь и т.д.?

М: Я пишу всё в midnight commander, т.е. это mcedit. Так сложилось, что я писал посты у себя в ЖЖ об удобности навигации в norton commander like панелях, т.е. у меня вся моя ручная мышечная память заточена на навигацию курсорами и поискам по ctrl s, по каталогам. Кроме того это сразу показывает, где хорошие соединения с серверами, где плохие. Если плохие сервера, нельзя в mc сидеть, значит я не хочу даже туда заходить.

В: А как же личный сорт Emacs?

М: Да, но это не мой личный Emacs, это Emacs, написанный компанией Bluetail, которую Joe Armstrong сделал и продал за 150 млн в 2001 году или в 2003, не помню. Я просто взял его, он был написан, очевидно, для какого-то релиза Erlang, то ли девятого, то ли десятого, в общем, вообще какой-то очень древний релиз. Я его реанимировал, положил на последний сленг и, вот, там немножко дописал, добавил в Unicode. Очень приятный редактор, очень красиво сделан, ну я имею в виду само, вот, это дерево редактирования. Оно там, если вы вставляете где-то символ, оно его режет, этот бинарь на пополам, вставляет туда этот символ, потом все это мерджит. Там все очень круто сделано. Если кто-то хочет посмотреть, как пишется на Erlang такая штука, как текстовый редактор, все очень похоже на хаскелевские yi, только все намного проще, т.к. по-колхозному делали, ну как все в Erlang у нас по-колхозному делается без типов. Вы понимаете.

А: Да. И такой вопрос, что означает твой псевдоним Namdak Tonpa, что это?

М: Это тибетское имя.

А: Ты его просто нагуглил или как?

М: Нет, мне его дали.

И: У него есть значение какое-то, перевод или еще что-то?

М: Чистый учитель.

А: Чистый или честный?

М: Чистый.

А: Чистый. А ты, я так понял, реально буддист или что?

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

В: Энтерпрайзненько. Простите, я надеюсь не оскорбляю ничьи чувства, звучит энтерпрайзненько.

М: Да, у меня есть лицензия на преподавание буддизма.

И: Слушай, круто.

А: Ну, я не знаю, вроде всё обсудили? Но я еще могу спросить такой бонусный вопрос, может быть мы его вырежем, как так получилось, что в интернетах ты такой тролль, а в подкасте такой, ну, нормальный вроде чувак?

М: Я просто, а кого я троллю в интернетах? Я пишу себе в ЖЖ.

И: Четко.

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

А: Я тоже считаю, как блогер, что, вот, я ж никого не заставляю читать мои бложики, если вы с чем-то не согласны, ну, не читайте. Ну, ладно, давайте тогда на этой позитивной ноте быстренько свернемся потому, что время вышло, как ни прискорбно, но не делать же три выпуска, в самом деле. Это был EaxCast, второй сезон, восьмой выпуск. С вами был Afiskon, Вань, я не вспомню, назови сам.

И: Просто Иван. Максим, спасибо тебе большое, было очень интересно.

А: Иван, Максим и Sum3rman.

В: Пока.

М: Спасибо ребята, до свидания.

А: Всем пока.

Дополнение: EaxCast S02E09 — интервью с Ильей Ключниковым о суперкомпиляции и ее использовании в IntelliJ IDEA

Метки: EaxCast.