Всем привет. Некоторое время назад (в общем-то, уже с полгода как) мне предложили напечатать в "Компьютерре" небольшое интервью с разработчиками языка Nemerle (интервью о Nemerle, естественно). "КТ" по каким-то причинам (неформат, наверное) интервью публиковать так и не стал, так что публикую его тут — может, кому-то будет интересно.

Ниже перевод интервью на русский язык, оригинал на английском в ответе на это сообщение.

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 библиотеками в повседневных задачах.

PS: Выражаю отдельную благодарность Зверьку, который сподвиг меня на то, чтобы взять интервью у этих замечательных польских парней, которые делают замечательный язык

Q1: What makes Nemerle better then other languages? (i.e. Why it's cool?)

Kamil Skalski:

Currently for me it is bringing the extensibility (macros) and ease of use (type inference, pattern matching) into the world of enterprise frameworks and commonly used object-oriented model for programming. This way developers have much more freedom in their designs and even the most complex (but innovative) of their ideas can be coded in a readable, elegant and statically-typed way.

Michał Moskal:

What I'm doing right now is automated theorem proving. It requires a lot of proof-of-concept implementations and testing. And of course there are hardly any books that will tell you: you need to do this and that, and even if there are you need to figure out the details yourself.

I've found that Nemerle is great at sketching implementation. You write some code, think a bit, change it, write some more, change it, test it. IMHO it is almost as good at it as interpreted, untyped languages. There are a few reasons.

One is type inference. Hmm... "let's change this list into dictionary", in C# you change:

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

into

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

in Nemerle you change:

def foo = []

to

def foo = Hashtable()

which is like a 10 times less annoying (even with intellisense).

The next reason is macros. I've written a few special-purpose macros, for example one that makes objects backtrackable (you can save their state at some point and restore it later). When I add a new field to such an object, I only need to mark it with [Copy] and everything is fine. In C# I had to add it in 4 places. Again this is not that important if you know what do you want to code upfront. But I don't. Another example are the profiling macros (and no, regular profilers don't do the job for me).

Pattern matching is also very useful here, and also extensible — you can go and add some special cases here and there.

The last reason is indentation syntax. It makes the program visually 20% shorter.

And of course, the performance is critical in automated theorem proving. Nemerle delivers something like 60-30% of raw C performance (on Mono). The difference is offset by the more advanced heuristics that you can code more easily code in Nemerle.

To wrap it up: Nemerle is great language for sketching of code almost as easily as in P-languages (Python, Perl, PHP), that will however deliver much better performance.

Q2: Why Nemerle is not mainstream yet? (and When will it be mainstream, as you think?)

KS:

My guess is that people do not value static typing and functional programming approach so much yet. But it is slowly changing — some of the language features provided by Nemerle are also available through languages like Python or Ruby, but in a dynamically-typed and imperative setting. I think that together with increasing complexity of IT projects (demand for static typing) and usage of parallel computing, Nemerle (or languages introducing similar features and approach) will become mainstream.

MM:

It either takes a major industry company backing it or several years and a lot of luck for a language to become mainstream. One regularity I see here is that successful open source initiatives to create programming languages are exclusively imperative, dynamic languages like Perl, Python and PHP (unless you call OCaml mainstream). Maybe this is because they are easier to design right and implement right. The other reason might be that they are easier to learn. Nemerle has a quite steep learning curve. There are benefits at some point of this curve but you don't really see them, until you try to write something bigger than a few dozens of lines.

Q3: Why have you decided to create new language at all (because there are a lot of different languages available)? Was it your first language designed?

MM:

So I guess I was the one to come out with the idea. It wasn't my first language. Before that I've implemented a kind of bourne Unix shell (interpreted of course).

Then an object-oriented C++-like language designed for writing AI-like bots for computer games. It run on a special-purpose virtual machine, and I guess wasn't very useful.

Than there was Ksi, which was a very low-level language, that could be used as a target for compilers of more sophisticated languages. It was very tightly bound to GCC internal syntax. It was implemented as a GCC frontend.

Then there was Gont, which was a cross between C and ML. It had parametric polymorphism and functional values, all in a C-like syntax with a conservative garbage collector that allowed for reasonably easy C interoperability. This was my first bootstraping compiler (i.e. one that was able to compile itself). The lesson learned was a/ don't try to use C-like syntax at all price and b/ even easy interop isn't easy enough — it has to be zero-cost.

The lesson a/ was the reason why Nemerle once looked much like Caml. Now I think it looks fine — we've managed to find the right spot between curly-braceness and functional-programming-friendliness. Lesson b/ was the reason to choose .NET.

As far as I can tell nobody seriously used any of these languages (except, of course, for Nemerle).

And now I'm in the world of first order logic, a language set in stone a hundred years ago

Q4: Macros are in the air since Lisp times. How do you think, why are they still not mainstream? (Maybe they are too complex for mainstream developer?)

KS:

Yes, I think that complexity in development and debugging of macros is one of the reasons why they were not fully adopted in mainstream languages. But I think that the main problem is that they were always either attached to the language not acceptable as mainstream by other reasons or simply badly implemented (like in C preprocessor macros). We hope that having powerful macros available in easy to use and portable language can change this situation.

Q5: C# 3.0 offers a number of features similar to Nemerle ones but it doesn't allow developers to extend language syntax. Why do you think giving developers an ability to modify language itself is better then having a restricted, well-designed set of language extensions in each new version (like they do it in C#)?

KS:

Developer who is fully aware of the language's power, always has the ideas for extensions, which would be useful in his problem domain. There is no such thing like "well-designed set of language extensions", software development is too diverse and fast-changing to define universal set of constructs for any task. It's like saying "we won't allow developers to create libraries, it's better to have single centralized kernel/framework, which we will simply update each year with new functions". Just take a look at "for (type x : collection)" construct in Java — it took almost 10 years of forcing developers to use those ugly iterators, until they added this ultra-simple language construct.

Q6: MS way for metaprogramming is external tools and external languages (DSL Tools for VS). Why do you think extending existing language with macros is better?

KS:

Probably the greatest advantage of macros is better integration and easier usage. You do not need to remember about additional classes, which have to be regenerated in specific circumstances, you don't even need to know about their existence — with appropriate macro it will just work. You can apply macros to every part of your code, altering your program at any depth with instant advice from compiler about the results. And moreover, everything stays unified — once you know the core language, jumping into macros is not too difficult and lets you stay in the same mindset.

Q7: Have Nemerle changed your own coding style?

KS:

I think that having all the features from different paradigms available in one language thought me to better understand the advantages and disadvantages of given approach to coding some solution. Also, I learned to use more declarative style of programming in practice — it all comes from functional programming where you concentrate rather on writing "transformers" of data, instead of "mutators", but only being able to use this approach with rich .NET libraries on everyday tasks did work for me.

Здравствуйте, Oyster, Вы писали:

O>Всем привет. Некоторое время назад (в общем-то, уже с полгода как) мне предложили напечатать в "Компьютерре" небольшое интервью с разработчиками языка Nemerle (интервью о Nemerle, естественно). "КТ" по каким-то причинам (неформат, наверное) интервью публиковать так и не стал, так что публикую его тут — может, кому-то будет интересно.

Нашёл опечатку: "памаретрический полиморфизм"