Q1: Почему Nemerle лучше, чем другие языки?

Kamil Skalski:

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

Michał Moskal:

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

Я выяснил, что Nemerle хорошо подходит для прототипирования. Ты пишешь код, думаешь немного, меняешь его, пишешь ещё, меняешь снова и тестируешь. По-моему, в такой ситуации Nemerle не хуже, чем интерпретируемые, нетипизированные языки, по нескольким причинам.

Одна из них – вывод типов. Хмм... «давайте-ка заменим этот список на словарь». В C# прийдётся поменять:

List<int> foo = new List<int>();

на

Dictionary<int,int> foo = new Dictionary<int,int>();

В Nemerle достаточно поменять:

def foo = []

на

def foo = Hashtable()

что, пожалуй, раз в 10 менее раздражительно (даже учитывая IntelliSense).

Следующая причина – макросы. Я написал несколько специализированных макросов. Например, один из них делает объекты откатываемыми (можно сохранить их состояние в некоторый момент и восстановить его позже). Когда я добавляю новое поле в такой объект, мне достаточно пометить его атрибутом [Copy], и всё чудесно работает. В C# мне приходилось регистрировать поле в 4-х разных местах. Опять же, это не так важно, если ты знаешь, что ты хочешь написать дальше. Но я этого не знаю. Другой пример — профилирующие макросы (нет, обычные профайлеры мне не подходят).

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

Последняя причина – поддержка синтаксиса, построенного на отступах (indentation syntax). Это делает программу визуально меньше на 20%.

Конечно же, производительность также критична для автоматического доказательства теорем. Производительность кода на Nemerle составляет где-то 60-30% от производительности кода на чистом Си (это на платформе Mono). Разница покрывается более продвинутыми эвристическими алгоритмами, которые проще писать на Nemerle.

Итого: Nemerle — отличный язык для такого же простого прототипирования, как в P-языках (Python, Perl, PHP), предоставляющий, тем не менее, гораздо лучшую производительность.

Q2: Почему Nemerle до сих пор не стал «мейнстримом»?

KS:

Я думаю, что в наше время люди не очень ценят статическую типизацию и функциональный подход. Но ситуация потихоньку изменяется — некоторые из языковых возможностей Nemerle также есть в языках вроде Питона или Руби, но в динамически-типизированном и императивном виде. Я думаю, что с увеличением сложности IT-проектов (что потребует статической типизации) и использованием параллельных вычислений Nemerle (или язык, предлагающий похожие возможности и подходы) станет индустриальным стандартом.

MM:

Для того, чтобы стать «мейнстримом», языку нужна или поддержка крупнейшей в индустрии компании, или несколько лет и куча вечения. Одна закономерность, которую я здесь вижу, это то, что успешные опенсорсные инициативы по созданию языков программирования относятся исключительно к императивным, динамическим языкам вроде Perl, Python и PHP (не считать же OCaml «мейнстримом»). Может быть, это потому, что их легче правильно спроектировать и правильно разработать. Другой причиной может быть то, что их легче учить. Кривая обучения у Nemerle довольно крута. В некоторой точке этой кривой становятся доступны преимущества языка, но их не будет видно, пока не попробуешь написать нечто большее, чем несколько десятков строк кода.

Q3: Почему вообще вы решили создать новый язык (ведь уже существует множество различных языков)? Был ли это первый спроектированный вами язык?

MM:

Я думаю, это была моя идея. Nemerle не был моим первым языком. Перед ним я написал разновидность BASH (интерпретируемую, конечно).

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

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

Потом появился Gont, который был чем-то средним между C и ML. Он поддерживал параметрический полиморфизм и функциональные значения (functional values), всё это с Си-подобным синтаксисом и консервативным сборщиком мусора, позволяющим сделать взаимодействие с Си разумно простым. Это был мой первый самокомпилирующий (bootstrapping) компилятор. Полученным уроком было а) не пытайся использовать Си-подобный синтаксис любой ценой и б) даже «простое» взаимодействие с другими языками не является достаточно простым — оно должно вообще ничего не стоить.

Урок а) был причиной, по которой Nemerle когда-то выглядел очень похожим на OCaml. Сейчас, я думаю, он выглядит нормально — мы смогли найти баланс между фигурно-скобочностью и ФП-дружелюбностью. Урок б) был причиной для выбора .NET.

Насколько я знаю, никто всерьёз не использовал ни один из этих языков (кроме Nemerle, конечно).

Ну а сейчас я в мире логики первого порядка – языке, сформировавшемся сотни лет назад

Q4: Идея макросов витает в воздухе со времён Лиспа. Как вы думаете, почему они так и не стали «мейнстримом»? (Может быть, макросы слишком сложны для индустриального разработчика?)

KS:

Да, я думаю что сложность разработки и отладки макросов — это одна из причин, по которой они не были полностью реализованы в «мэйнстримовых» языках. Но основная проблема, по-моему, в том, что они всегда или шли вместе с языком, неприемлимом в «мэйнстриме» по другим причинам, или просто были плохо реализованы (как макросы препроцессора Си). Мы надеемся, что наличие мощных макросов в простом для использования и портабельном языке сможет изменить ситуацию.

Q5: C# 3.0 содержит некоторые возможности, похожие на аналогичные возможности Nemerle, но не позволяет разработчикам расширять синтаксис языка. Как вы думаете, почему давать разработчикам возможность модифицировать сам язык лучше, чем иметь ограниченный, хорошо спроектированный набор расширений языка в каждой новой версии (как это сделано в C#)?

KS:

У разработчиков, полностью постигших мощь языка, всегда есть идеи для расширений, полезных в их предметной области. Не существует такой вещи как «хорошо спроектированный набор расширений языка», разработка ПО слишком многообразная и быстро меняющаяся дисциплина для того, чтобы определить универсальный набор конструкций для любой задачи. Это то же самое, что говорить: «Мы не позволим разработчикам создавать библиотеки, лучше иметь единственное централизованное ядро, в которое мы просто будем добавлять новые функции раз в год». Посмотрите, к примеру, на конструкцию «for (type x : collection)» в Java — заставить разработчиков использовать эти ужасные итераторы удалось только через 10 лет, когда они добавили эту ультра-простую конструкцию языка.

Q6: Подход MS к использованию метапрограммирования базируется на внешних утилитах и внешних языках (DSL Tools for VS). Почему, по вашему мнению, расширение существующего языка с помощью макросов лучше?

KS:

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

Q7: Изменил ли Nemerle ваш собственный стиль написания кода?

KS:

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