Re: Что лучше делать на Nemerle вместо C#
От: hi_octane Беларусь  
Дата: 22.05.11 21:34
Оценка: 202 (14) +3
D>В чем C# уступает (если, конечно, уступает) Nemerle? Что можно сделать Nemerle легче, чем на C#?

Тут вопрос стоит ставить иначе. А есть ли что-то вообще что можно сделать на C# так чтобы было лучше чем в Nemerle

1) Любая сложная логика. То что на C# выражается кучами вложенных if/else — на Nemerle занимает в разы меньше места и читается нагляднее. См match
2) Многопоточность. После того как привыкнешь писать в immutable стиле и накидаешь основные примитивы макросами — C# вообще отдыхает. У нас к концу проекта основных примитивов многопоточности набралось штук наверное 20. В C# — lock в зубы, и остальное выписывай ручками в кренделя try/finally.
3) Всё что может дать аспектно-ориентированное программирование — на Nemerle и проще сделать, и возможностей будет больше, и проще расширять.
4) Задачи требующие своего DSL.
5) Логгирование, замеры времени, особенно если проект в релизе, его как в C# не делай, всегда фигня будет получаться
6) Задачи, которые на C# принято считать требующими кодогенераторов или отдельных программ. У нас например в процессе компиляции макрос лезет по сети и вытягивает оттуда JavaScript, а потом лезет по всему проекту, и в нужных местах корректирует код (не какие-то генерённые файлы обновляет, а разбирает и корректирует писанный людьми код), в соответствии с тем JavaScript. Чтобы такое повторить на C# — убиться надо.
7) Даже самые простые вещи об которые спотыкается C#. Вот сделай мне чтобы прога при старте выводила дату/время компиляции и машину на которой билдилась, без посторонних приблуд и отдельных прог или там чек-сумму ключевых исходников посчитай
8) Форматирование строк, нам приходилось переключаться между обоими, так после Nemerle форматируешь строки в C# и плачешь, плачешь...
9) Поддержка прямо в языке XML, или JSON, или любого другого формата.
10) Возможность поддержать кучу разных видов сериализации одним макросом, и при этом не написать ни строчки рукопашного кода (нам реально надо было).
11) Генерировать что-то по коду проекта в процессе компиляции. Например javascript или базу данных. В C# БД генерировать умеет только наверное DevExpress XPO, и то через рефлексию и по рабочей программе а не во время компиляции. И со всякими ограничениями. В Nemerle можно в генерированную БД из бакапа например тестовые данные сразу вытягивать, если билд тестовый.
12) Статическая верификация кода. Например можно разрешить вызов каких-то методов только из под правильного lock'a. Или наоборот запретить вызов из под lock'a например методов которые заведомо долго работают.
13) В C# есть только typeof. Больше ничего нет и не будет, потому что Эрик Липперт. В Nemerle можно и memberof, и propertyof, и чё угодно. Реально это надо когда например пишешь такой код throw ArgumentOutOfRangeException(arg(имя_аргумента)); или там биндинг на какое-то поле делаешь. В C# только строчки "имя_аргумента" для этих целей. Которые может какой Resharper и проверяет в простых случаях, а может и нет.
14) Вывод типов. В C# его нет, поэтому даже сложно как-то объяснить насколько проще пишется когда он есть.
15) Код реально лучше и удобнее с фичами вроде локальных функций, объявления переменных внутри пропертей (и соответствено недоступных другому коду), всяких макросов автогенерации вроде [Record], и т.п.
16) Собственные операторы. В C# кроме нескольких захардкоженных ничё нельзя. В Nemerle хоть #@$! объяви, если он для тебя имеет смысл, то пользуй и радуйся.
17) То что любой из вышеперечисленных, а также любой из фич которые я не знаю/забыл можно не пользоваться вовсе. И писать как раньше писал на C#
18) Если припрёт то можно даже множественно наследование слепить. Нам на проекте не понадобилось, но как proof-of-concept чего-то накидали пока изучали тему макросов.

D>Есть ли такие задачи, для которых алгоритм на Nemerle будет работать быстрее, чем на C#?

Оба языка на .NET, так что их быстродействие очень близко. В среднем, по слухам, код генерируемый на C# чуть быстрее.
1) Абсолютное большинство задач требующих рефлексию, описанные на Nemerle будут работать лучше и быстрее — например сериализация обычная и XML, соответственно и работа с сетью если используется сериализация, и т.п.
2) В качестве общего развития почитай про проект NUDA — там код Nemerle в процессе компиляции преобразуется в код расчёта на GPU. Если алгоритм критичен по скорости — ты можешь повторить этот же трюк, но транслировать Nemerle в тот же C++ например, причём штатными средствами самого Nemerle.
3) Регулярные выражения. В C# они тормозные, в Nemerle их реально сделать быстрыми если надо. Кроме того в Nemerle есть regex match, для быстрого биндинга вхождений.


Тем не менее в Nemerle есть и некоторые неудобства.
1) Скорость компиляции. Мы решали этот вопрос тупым апгрейдом всего железа. Никто не возражал
2) Интеграция с Visual Studio иногда отваливалась. В частности автокомплит пропадал. Решалось либо перезапуском, либо закрывали все окна и открывали снова. Как повезёт.
3) Проекты где используется WinForms/WPF/другие студийные дизайнеры. Поддержка дизайнеров хронически хромает. В основном потому что работа этих студийных дизайнров нифига не документирована, и по-видимому никогда не будет документирована, да ещё и индусописана (сам в них лазил). Пока лучше делать фронт-энд на C#, логику на Nemerle. Если в терминах MVC/MVVM то Nemerle идеален для Model.
4) Поддержка Linq, в C# Linq заинлайнен, сразу from и запрос. В Nemerle он мощнее, но приходится писать linq <# from .... #>. В Nemerle 2 исправят. Хотя имхо могли бы грязным хаком исправить и пораньше
5) Информирование об ошибках. Иногда читая ошибку теряешься. Это от того что можно комбинировать самые неожиданные вещи, и компилятор встретив что-то не то, тем не менее находит в этом какой-то смысл Например путаешь параметры местами, а компилятор может тебя заподозрить в попытке заиспользовать ковариантность.
6) То что некоторые фишки о которых и не подозреваешь, можно узнать только потусовавшись на форуме или случайно заметив в сорцах компилятора.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.