Language with a Bright future

[thedeemon]

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

1. Web Development in D - какие есть замечательные инструменты (в первую очередь vibe.d), как с ними все получается просто и красиво (и эффективно), благодаря грамотному использованию возможностей D.
2. Writing Testable Code in D - тут больше демонстрация умений и удобств языка.
3. Metaprogramming in the Real World - занятный experience report от компании с сотней программистов, где весь код пишется на D.

Comments

[xeno-by.livejournal.com]

Да и вообще, как народ юзает МП в D? Какие самые типичные юзкейсы?

[thedeemon.livejournal.com]

Заметные примеры - регекспы и PEG-парсер, которые подготавливаются и оптимизируются в компайл-тайме.

Типичные же юзкейсы - это получить на вход некоторый заранее неизвестный тип Т, используя развитую компайл-тайм рефлексию разузнать, подходит ли он и что он умеет, и на выходе родить новый тип R, сохраняющий или преобразующий полезные свойства Т и делающий что-то свое. Например, так комбинаторы map/take/reverse/zip и т.п. сохраняют такие свойства переданных в них последовательностей как "известная длина", "клонируемость", "доступ по индексу за О(1)" и т.д. Или, например, берется на вход некоторый класс и возвращается его аналог, где методы превратились в RPC вызовы или наоборт обработчики RESTful запросов. Вся рефлексия и рождение кода происходят при компиляции, рантайм-оверхед нулевой.

Ну и всевозможная сериализация-десериализация, конечно.

[xeno-by.livejournal.com]

Насколько юзают МП для дслей? А для верификации кода?

[thedeemon.livejournal.com]

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

[xeno-by.livejournal.com]

А еще такой вопрос. Что тебе не нравится в дишном метапрограммировании?

[thedeemon.livejournal.com]

Если говорить в целом, как о подходе - не знаю, надо подумать.
А если про конкретную реализацию, то:
1. Порой хочется увидеть результат раскрытия всех шаблонов. Вон в Си можно посмотреть результат препроцессора, в GHC куча всяких промежуточных представлений доступна, а тут я не знаю, как заглянуть в середину между исходником и бинарником. Воможно, в GDC или LDC что-то такое есть, не в курсе.
2. Сообщения об ошибках порой не шибко информативные. Например, если есть несколько реализаций шаблона с разными предусловиями, и ни один предикат не сработал, то шаблон не инстанциируется, при этом сообщение об ошибке может быть весьма неожиданным, приходится догадываться.
3. Если писать сложный код в ФП-стиле, где замыкание внутри замыкания замыканием погоняет, и все передаются как alias параметры во всякие комбинаторы, компилятору порой сносит крышу.

[xeno-by.livejournal.com]

Касательно коллекций. Вот в Скале похожая функциональность реализована на фандепах без всякого метапрограммирования. С одной стороны, получается немного awkward программировать на языке тайпклассов. С другой стороны, не нужно никакого МП, т.е. все строго на типах, без компайл-тайм рефлексии. Какой подход ты бы предпочел?

[thedeemon.livejournal.com]

Я не знаю, как именно это выглядит в Скале. В D подобная логика выглядит настолько straight-forward, что сложно представить что-то более подходящее. Через шаблоны и CTFE можно иметь предикаты и функции на типах произвольной сложности, а static if c ними позволяет гибко менять компоненты и свойства строящегося типа. Не нужно вводить целый под-язык тайпклассов.

[xeno-by.livejournal.com]

Как в D написать функцию map, которая: 1) определена для всех коллекций (листов, векторов, чего угодно, соответствующего базовому интерфейсу), 2а) на выходе выдает ту же самую коллекцию, параметризованную типом результата маппера, 2б) за исключением случая, когда маппер возвращает Boolean - в таком случае возвращаемый тип map должен быть BitVector.

Что-то типа:
map(List(1, 2), x => x) возвращает List[Int]
map(Vector(1, 2), x => x.toString) возвращает Vector[String]
map(Map(42 -> "42"), x => true) возвращает BitVector

[thedeemon.livejournal.com]

Это надо придумывать заново базовый интерфейс, а у меня уже третий час ночи. Вот дишный подход, он несколько отличается, в частности map получается ленивым (kinda):
http://ddili.org/ders/d.en/ranges.html
Сейчас контейнеры умеют представлять себя в виде рэнждей, с которыми работают всевозможные алгоритмы и комбинаторы. Если контейнерам еще добавить универсальный способ создаваться из рэнджей (не помню, есть ли это сейчас), то запрошенная тобой функция будет совсем простой. Завтра могу попробовать сделать пример.

[xeno-by.livejournal.com]

Спасибо, было бы здорово!

[xeno-by.livejournal.com]

Слушай, я вот тут еще подумал. Можно ли на дишечных шаблонах наколбасить LINQ, т.е. чтобы шаблоны каким-то образом преобразовывали лямбды, передаваемые в map/filters/etc, в сиквел?

[thedeemon.livejournal.com]

Шаблоны внутрь переданных функций вроде как не могут заглядывать, но задача наверняка решается с помощью
http://en.wikipedia.org/wiki/Expression_templates
т.е. сделать лямбды не простыми, а строящими AST. С перегрузкой операторов это не так сложно.

[xeno-by.livejournal.com]

С виртуализацией есть свои проблемы. Например, как лифтить константы или что делать с дереференсом филдов.

[xeno-by.livejournal.com]

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

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

Конечно, когда я читал посты и тексты, в голове сразу начал работать сравнитель. С одной стороны, стратегия как в лиспах, как у нас, когда вычисления времени компиляции спрятаны за макросами, которые основаны на reflection API. С другой стороны ди, в котором есть куча разных средств CTM (как утверждает один пост, "here is the basic tool box: typeof, is, alias, static if, __traits, std.traits, CTFE."), которые можно юзать вперемешку с кодом.

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

[thedeemon.livejournal.com]

Тут у меня недостаточно опыта для сравнения. Я видел много разных попыток сделать удобные лисп-стайл макросы (camlp4, nemerle, haxe, какие-то кусочки скалы...), и везде это пляски с бубном, часто отдельные фазы компиляции, отдельный синтаксис и длинное страшное слово "метапрограммирование". Отсюда и стеснение. В D же просто берешь и пишешь generic код, даже и мысль о таком длинном слове не приходит.

[xeno-by.livejournal.com]

Да, это меня очень впечатляет.

[xeno-by.livejournal.com]

http://xeno-by.livejournal.com/86554.html