NEMERLE и поток сознания

[stdray]

Сначала я хотел просто написать, что майский конкурс по ФП закончился, и желающие могут посмотреть, что мы там устроили. А если что-то из увиденного понравится, то и проголосовать.

Но потом я подумал, что это хороший повод рассказать о языке программирования Nemerle, с которым я игрался в последнее время. Опыт у меня с ним пока не большой, потому структурировано написать не выйдет. Под катом некторый набор сведений о Nemerle в перемешку с моим потоком сознания относительно функционального программирования и программирования вообще.


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

Спасибо мне! Сыграл в КО! Однако с языками программирования часто не прокатывает. Осилил %langname% и все, хватит, отвалите. Мне труп страуса нашептал, что у меня в руках ИНСТРУМЕНТ ВЫСОКОГО УРОВНЯ, а потом, прищурившись, добавил: "Полный по Тьюрингу, даааа". Ну теперь вообще ахуеть. Я даже слушать вас не хочу: жаба тормозит, сишка хуже ассемблера, додиез не знаю, зачем придумали, когда у них жаба есть, objc - это просто яблочная илитка, на лиспе искуственный интелект так и не зделали, лямбда-исчисление? исчисление что? Шли бы вы отсюда со своими историями. А потом человеку изменяет сознание и он начинает находить свои любимые костыли даже там, где их никогда и не было. Паттерн ПРИСПОСОБЛЕНЕЦ во все поля.

Я вспоминаю, как начав программировать на C#, испытывал физическую необходимость ОСВОБОДИТЬ ПАМЯТЬ и руками устроить связанный список. Потом-то оно уже проще идет. Знакомые вещи определяются сразу, а новые расширяют кругозор. Интересно узнавать новый язык, задаваясь вопросом: "А как я вообще раньше без этого жил?" Как будто собирается некий пазл, образуя целостную картину, а не "Вот тебе походный ножик. Теперь иди - строй дом".

Казалось бы, причем здесь Nemerle? Просто это язык программирования, который, на мой взгляд, заслуживает внимания.

Nemerle - ЯП общего назначения. Я не знаю, что такое общее назначение. Я так мало знаю о программировании микроконтроллеров и о программировании для суперкомьютеров и еще куче областей , что у меня с парнями, работающими в тех сферах, разная специальность. Я понимаю, что хороший программист должен найти себя в любой области, но у нас _настолько_ разные приоритеты, что придется сильно ломать себя. Я пишу средней толстоты эторпрайз (базворды прилагаются), потому для меня важны:
- Надежность. Ведь ничего падать не должно, а если упадет - перезапуститься. Конечно же, все логировать-логировать и алертить. И желательно все это задублировать.
- Прозрачность. Ведь вон та функция "ОТПРАВИТЬ ДЕНЬГИ НА ПЕЧАТЬ", должна отправлять деньги на печать всегда, а не только в состоянии суперпозиции ста тысяч "Если".
- Читаемость. Ну мы же все знаем, что самодокументируемый код - это миф, не так ли? Правда, мы так же знаем, что документирование всего и вся с последующей актуализацией - тот еще кошмар. Потому лучше писать кратко и информативно.
- Тестируемость. Необходимо проверить исправность каждой детальки еще до момента, когда конструктор будет собран. Мы же не хотим ОТПРАВИТЬ ЯЧЕЙКУ НА БОЕВОЕ ДЕЖУРСТВО, ЧТОБЫ ОНА ТАМ ПРОСТО СИГНАЛ РИСОВАЛА ТАБУРЕТОЧКОЙ, так?
- Совместимость. Хаскель исключительно хорош для новых проектов? А если не новых? Вместо библиотек даете возможность их написать? ВЕРНИТЕ НА МЕСТО МОИ ЛЮБИМЫЕ ВЕЛИКИ! БЫЫЫСТРААА!

Nemerle - статически типизуеммый язык программирования под .NET (есть реализация для Mono, но она вроде сломана) со всеми вытекающими. Язык поддерживает ООП в самом распространенном варианте ее реализации с одиночным наследованием, знакомый по Java и C#. Есть:
- Шаблоны (generics)
- Интерфесы
- Методы расширения
- Частичные (partial) классы
- Модификаторы доступа (internal, protected и тд)
- Весь набор, привычный C# программисту. )

Я не вижу смысла, останавливаться на ООП, потому как все достаточно стандартно. Идем далее. Nemerle реализует концепции функционального программирования:
- Нормальные кортежи
- Алгебраические типы данных
- Иммутабельность из коробки
- Паттерн матчинг
- Функции высшего порядка
- Частичное применение
- Вывод типов
- Замыкания
- Перегрузка и определение операторов с возможностью задания приоритета и ассоциативности
- Итераторы
- List comprehensions (не знаю, как переводится)
- Монады (нет, ввод-вывод не в монаде)
- Computation expressions (опять не знаю устоявшегося перевода)
- Опционально двухмерный синтаксис (синтаксис на отступах) через #pragma indent
- Опционально может в ленивость
- Оптимизация хвостовых вызовов
- События и делегаты (я думаю, эти вещи в этом блоке смотрятся лучше)

Вообщем-то весь джентльменский набор, необходимый, чтобы назвать язык функциональным. Стоит отметить, что Nemerle разрешает перегрузку функций (в отличии, например, от F#) и вывод типов спокойно разруливает, какую именно следует вызвать. Мне нравится, но наверное хаскелисты негодуют. Правда, Nemerle требует, чтобы на высшем уровне, то есть в классах и модулях (модуль является обычными статическим классом, для методов которого по умолчанию выставлен модификатор public) необходимо явно аннотировать типы. Я не думаю, что кому-то станет плохо от подобного требования, поскольку даже в Haskell, где система типов способна сама все выводить, аннотации типов все равно приводятся, поскольку по типам можно судить о природе процесса, выполняемого функцией. Еще одной особенностью является возможность "открыть" статических класс, импортировав его содержимое в текущее пространство имен. Может мелочь, но меня всегда раздражали все эти Console.WriteLine.

То есть, на первый взгляд, Nemele ничего особенно не представляет. К тому же разработчики старались не сломать мозг своей потенциальной аудитории, потому сделали синтаксис языка по возможности идентичным C#. Разработчики Scala, как я понимаю, пошли тем же путем. А вот ML-подобный синтаксис с непривычки может очень сильно напугать. Проверено. Язык задумывался, как замена C#, то есть каким C# должен был бы быть. И вы знаете, я согласен. Этих возможностей вполне хватает, чтобы комфортно программировать. F# как раз на этой позиции и находится, то есть со вкусом и без изъебств.

Теперь переходим к Nemerle непосредственно, к тому, что делает язык в большой степени уникальным, - макросам. У меня с макросами всегда были проблемы, сначало звучало страшно, потом было непонятно, где и как и применять. Похоже, это не только моя проблема. Иногда, я думаю, что после изобретения LISP'а, значительная часть развития языков программирования является размышлением на тему "Нужны ли макросы? Какими они должны быть тогда?" LISP'еры хоть и не изобрели искустевеный интелект, но очень многое дали миру: gc, графические интерфейсы и конечно макросы. Мне кажется, Ритчи с Томпсоном догадывались, что всего не предусмотришь, потому запили макры. Сишка используется до сих пор, многие даже испытывают к ней теплые чувства. А более другие люди решили, что макры не нужны, а теперь гордятся тьюринг-полным ТЕМПЛЕЙТО-ДОБРОМ. В Скалочку вот добавляют макросы, а я не видел, чтобы кто-то писал, мол Мартин Одерский не особо рубит в языках программирования.

Так с макросами какие проблемы? Во-первых, сразу начинается нытье, мол развалите весь синтаксис со всей семантикой, превратив язык в непонятную ёбу. Я так же ныл (может еще заною, кто его знает). Но это возврат к разговору о возможности прострелить себе ногу. Меня подзаебали эти разговоры, я решил для себя, что прострелить ногу можно везде и всегда. Мутабельность - прострелил. Энергичность - прострелил. Ленивость - иди чини ноги. Иммутабельность - не прочитал книгу по иммутабельным структурам данных? пиздуй в больницу чинить ноги. И так всегда, не бывает серебрянной пули, как не бывает языков общего назначения, как нет искуственого интеллекта. Именно поэтому, программисты существуют, существуют как профессия, как специалисты, а не просто прослойка между креслом и монитором. Хотя надо отдавать себе отчет в собственных возможностях. Это вам не придти и перевести все критические бизнес-процессы на Хаскель из-за того, что кто-то научился Фибоначи считать. И я не один такой, создатель Лифта такой же точки зрения придерживается. То есть в любом случае некоторый опыт необходим.

Во-вторых, макросы сложные. В Nemerle не сложные, то есть при написании макросов используется тот же самый Nemerle и его возможности, никакого специального DSL не требуется. Держим в уме знание, что макрос - функция с типом List[PExpr] -> PExpr, выполняемая во время компиляции, и все будет хорошо. Макросы гигиеничны, то есть при совпадении имен переменной из макроса и контекста, в котором макрос разворачивается, имя из макроса будет автоматически переименовано, хотя это поведение можно отключать, тогда значение будет связано с ближайшим именем в контексте. Таким образом, кстати, работает макра regex match, которую я использовал в своем решении.

Макросы бывают разными
- Макросы выражения: можно сделать printf("%d%f", x, y), который будет на этапе компиляции проверять соответствие количества параметров и их типов строке форматирования; многие компоненты языка такие как if else, while, for и другие реализованы через такие макросы
- Макросы-операторы: собственно через них реализует переопределение и создание новых операторов. Можно задавать приоритет и ассоциативность. Например, с их помощь в Nemerle сделаны pipe-операторы |> и <|
- Мета-атрибуты - видимо, так называются из-за сходства в записили с атрибутами C#. Позволяют изменить класс, метод, свойство и так далее. Для меня самый впечатляющим примером использования является макрос PegGrammar, который по заданной PEG грамматике создает класс-парсер ее разбирающий. Мой игрушечный пример можно увидеть тут. Если игрушки вам не по душе, то можно глянуть на серьезное использование для разбора грамматики C#.
- Лексические макросы: к сожалению, я еще не успел с этим разобраться, но похоже, макра конструирования XML, напоминающая синтаксис для работы с XML в Scala, относится именно к этой категории.

Мне очень хочется, рассказать о макросах Nemerle, кратко и содержательно, чтобы вы могли испытать то же ВАУ, которое испытываю я. Но, по всей видимости, пока в моем мозгу все по полочкам не разложится, я не смогу внятно излагать. Главное, что я хочу донести, что макросы в Nemerle - это очень гибкое средство, которое красиво и лаконично ложится на язык. Синтаксис языка во много сделан на макросах, кодогенерация требующая в C# сторонных тулзовин отлично реализуется, многие хорошие фичи, которые приходят в C#, как новые элементы языка, делаются на макросах. Я думаю, так ожидаемые Type Providers из F# 3.0 делаются на макросах на ура. То есть я пока не вижу, где заканчиваются возможности, но четко представляю, как применять эти вещи в работе: будь-то автоматическая имплементация всяких IDataErrorInfo с INotifyChanged или как присахарить и обезопасить работу с каким-нибудь SqlCommand. При этом я без проблем, могу использовать существующий C# код, могу использовать в C# проектах код на Nemerle (пока не тестировал). Я считаю, что Nemerle - более удобный и качественный инструмент для решения мох задач.

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


Update: Как-то получилось, что обсуждение велось параллельно в двух местах: тут и еще одна ветка обсуждения.

Comments

[hls-1141.livejournal.com]

Прочитал, интересно. Надо посмотреть на Немерлю и поделать макросов, вдруг затянет.

[yantayga.livejournal.com]

Спасибо за интересный пост.
А на какой версии .NET работает Nemerle?

[stdray.livejournal.com]

С 2 по 4, но самое новье сейчас конечно под 4 дотнет делается.

[(Anonymous)]

Гайдов мне гайдов.

[stdray.livejournal.com]

Начинать где-то здесь: http://www.rsdn.ru/summary/3766.xml
Продолжать где-то тут: https://github.com/rsdn/nemerle/wiki
Читать сами исходники немерли, благо они понятные: https://github.com/rsdn/nemerle
Спрашивать на rsdn можно.

[hls-1141.livejournal.com]

схоронил.

[metaclass.livejournal.com]

Я вместо Nemerle выбрал Clojure практически случайно. Для проекта были нужны макросы (конкретнее - надо сделать интеллектуальный мемоизатор тяжело-считаемых функций). Рассматривались только языки с нормальной интеграцией во внешний мир (Template Haskell - сразу фпень).

В Clojure оказалось:
1) Доступна вся жабья инфраструктура.
2) Автоматическая установка всех зависимостей, то бишь leiningen со всеми его фичами
3) Попался под руки понятный пример приложения с RESTful веб-сервисом внутри его.
4) Внезапно, при динамической типизации и функциональщине макросы и кодогенерация оказались почти не нужны.
5) Более логично устроен нежели Nemerle и более практично, чем Common Lisp.

[thesz.livejournal.com]

>Рассматривались только языки с нормальной интеграцией во внешний мир (Template Haskell - сразу фпень).

Huh?

[metaclass.livejournal.com]

Хаскель (под виндой) не пригоден для использования совместо с другими языками и бинарным API.
Готовых же либ, заменяющих необходимость в интеграции прямым использованием нужных внешних сервисов - или нет, или они кривые.
Короче, ситуация с хаскелем пока не совсем ясна, очень хотелось бы статик типизацию, но не выходит каменный цветок.

[stdray.livejournal.com]

1) Это большой плюс, потому я постоянно посматриваю в сторону Скалы, а до Кложи все никак руки не дойдут. Правда у нас тут все Windows и .NET, потому я сомневаюсь, что мне кто-то разрешит в Жабу играть.
2) Могу ошибаться, но в дотнете вроде нет проблем со сборкой, тем более Nemerle интегрируется со Студией ничуть не хуже родного F#.
3) Я не понимаю, зачем REST и как его использовать. Из того, что видел, сложилось впечатление, что на WCF можно сделать аналогичное поведение.
5) Я сходу не могу сказать, где в Nemerle кривота. В своей основе он же минималистичный совсем, а весь синтаксис - сахар из стандартной библиотеки.
4) Я понимаю, что имея лаконичный язык под рукой (очень симпатизирую Схеме) писать ровный код проще, но я все равно за строгую типизацию.

[metaclass.livejournal.com]

1) Попробуй clojureclr для дотнета. Придется 100500 либ конечно портировать, зато будет позитив)
2) проблем нету, ставить руками зависимости лень, мавена нету :)
3) REST охуенен. Он идеально укладывается на CRUD операции, отлаживается браузером, wget, curl, не требует от клиента НИЧЕГО, кроме умения делать запросы и работать с структурированным (json/xml) текстом.
4) в немерле как-то комьюнити слабоживое и русское. Это, на опыте Firebird - тупик для проекта.
5) я тоже за строгую. Но не вышел каменный цветок ни на чем, кроме лиспов)

[potan.livejournal.com]

Суд Oracle-Google показал, что доступность жабьей инфраструктуры скорее минус, чем плюс. Опять-таки требование совместимости с jvm не дает хвостовые вызовы оптимизировать.

[thesz.livejournal.com]

>Мне очень хочется, рассказать о макросах Nemerle, кратко и содержательно, чтобы вы могли испытать то же ВАУ, которое испытываю я.

Нормальный порядок вычислений (normal reduction order) снижает потребность в макросах на порядки. Не говоря уж про зависимые типы данных, в которых вообще проекции Футамуры самозарождаются как бы ниоткуда (и пример с printf является чуть ли не классическим, пусть в чуть более простом варианте).

[stdray.livejournal.com]

Наверное, я многого не понимаю, но

>Нормальный порядок вычислений (normal reduction order) снижает потребность в макросах на порядки

Как нормальный порядок вычислений снижает потребность в макросах?

Не говоря уж про зависимые типы данных

Вы про Хаскель? Там уже сделали зависимые типы? А можно пример? И printf из ниоткуда?

[(Anonymous)]

Нормальный порядок вычислений покрывает хорошо если 1% юзкейсов макросов, так что не знаю, где уж тут "на порядок". А вот зависимые типы, если есть макросы, не нужны, так как любая система типов выражается через макросы. Вообще, если упорядочить системы типов по возрастанию выразительности, то макросы - это точная верхняя грань полученного множества. Причем это формально строго утверждение, безо всяких преувеличений :)

[xeno-by.livejournal.com]

У тайп провайдеров есть виртуальный режим, когда сгенерированные типы в конце компиляции стираются и не компилируются в байткод. Фиг такое сделаешь на макросах, к сожалению.

[stdray.livejournal.com]

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

[xeno-by.livejournal.com]

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

Хорошей иллюстрацией является дискашен Macros vs String interpolation (еще одна новая фича в 2.10): http://groups.google.com/group/scala-debate/browse_thread/thread/1cab093fc21e4. В принципе, на макросах можно сделать то же самое на 90-95%, но потом начинаются проблемы типа интеграции с IDE или того факта, что пусть даже строку обрабатывает и макрос, но он не может сказать парсеру отменить для этой строки escaping, поэтому фиг поюзаешь бэкслеши в теле интерполируемой строки.

[stdray.livejournal.com]

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

>Macros vs String interpolation
В Немерле насколько я помню, это как раз через макру и сделано. Но вроде все корректно отрабатывает и бэкслэши можно юзать:

     def x = 100500;
     def str =  "test x \t = $x";
     def esc = @"test x \t = $x";
     WriteLine(str);
     WriteLine(esc);

вывод такой:

test x   = $x
test x \t = $x

Корректное поведение, на мой взгляд.

[Влад Чистяков (from livejournal.com)]

Какие проблемы:

WriteLine($"\t$(\"Nemerle\") cool!");

В Nemerle главное, чтобы строка была корректным литералом. А макрос разбирает не значение строки, а исхдик. Т.е. он анализирует все вложенные эксейп-последовательности

В N2 все буде еще круче. Каждый макрос (точнее правило грамматики) сможет сам парсить исходник. Никакого парсера не будет. Каждая макра сама предоставляет свой парсер. Соответственно возможности его будут ограничиваться исключительно возможностями фантазии программиста.

[(Anonymous)]

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

Непонятно, в чем проблема. Макросы в этом плане ничем не отличаются от библиотеки (которую легко можно сделать, так, чтобы она работала в твоем случае, но не в случае вон того чела), класс (аналогично) или даже просто функцию.

[-darkus-.livejournal.com]

Ох ты ж! Какая драма в комментариях!!!

[petropavel]

Не подскажете ли, что у меня не так?
contest.n:10:17:10:31: error : unbound name `ReadLines' in `File'
(Nemerle только что скачал, ничего в нём не понимаю))

[petropavel]

как я понял, ReadLines появился в .net 4,0
microsoft.com/en-us/download/confirmation.aspx?id=17718 - тут был,
Microsoft .NET Framework 4 (Standalone Installer) - оно поставлено.
Вижуал студии у меня нет, джава (извините) основной язык у нас.

[-darkus-.livejournal.com]

Коллега, я Вам там письмо электрической почтой опять послал. Давайте уже договариваться о встрече.

Или по Почтой России отправить куда?