Что лучше делать на Nemerle вместо C#
От: Darooma Россия  
Дата: 22.05.11 19:35
Оценка:
В чем C# уступает (если, конечно, уступает) Nemerle? Что можно сделать Nemerle легче, чем на C#?
Есть ли такие задачи, для которых алгоритм на Nemerle будет работать быстрее, чем на C#?
Re: Что лучше делать на Nemerle вместо C#
От: Ka3a4oK  
Дата: 22.05.11 19:56
Оценка:
D>Что можно сделать Nemerle легче, чем на C#?

Написать программу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re: Что лучше делать на Nemerle вместо C#
От: alvas  
Дата: 22.05.11 20:14
Оценка:
Здравствуйте, Darooma, Вы писали:

D>В чем C# уступает (если, конечно, уступает) Nemerle? Что можно сделать Nemerle легче, чем на C#?

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

Чего бы я НЕ писал на N, так это интерфейс для WinForms — глючат дизайнеры. Все остальное можно
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re: Что лучше делать на Nemerle вместо C#
От: catbert  
Дата: 22.05.11 21:28
Оценка: 3 (1)
Здравствуйте, Darooma, Вы писали:

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


Вряд ли. Но вполне возможно, что на Немерле можно намного проще и быстрее написать более эффективный алгоритм, чем на C#. Например, я хотел реализовать алгоритм Флойда-Уолшерра на C#, но так и не доделал, использовал брут-форс. А когда перешел на Немерле, реализовать алгоритм стало намного проще.
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) То что некоторые фишки о которых и не подозреваешь, можно узнать только потусовавшись на форуме или случайно заметив в сорцах компилятора.
Re[2]: Что лучше делать на Nemerle вместо C#
От: Аноним  
Дата: 22.05.11 21:49
Оценка:
Здравствуйте, hi_octane, Вы писали:

_>7) Даже самые простые вещи об которые спотыкается C#. Вот сделай мне чтобы прога при старте выводила дату/время компиляции

Есть в метаданных сборки
Re[3]: Что лучше делать на Nemerle вместо C#
От: hi_octane Беларусь  
Дата: 22.05.11 22:07
Оценка:
_>>7) Даже самые простые вещи об которые спотыкается C#. Вот сделай мне чтобы прога при старте выводила дату/время компиляции
А>Есть в метаданных сборки
Дата время есть. Проще всего из AssemblyInfo вытащить, можно из PE, наверняка есть и другие места. Но ты обрезал цитату рановато — там ещё было про имя билд-машины и чек-суммы ключевых исходников , а это уже фиг. У нас релиз клиенту отправлется только с одной машины, сбилженный человеком который лично всё два раза проверит, прежде чем собирать и отсылать. Если в качестве непланового багфикса какой-то левак и сбилдят — без большого красного свистка фиг запустится. Потому что цена ошибки высокая.
Re[2]: Что лучше делать на Nemerle вместо C#
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.05.11 22:30
Оценка: :))
Здравствуйте, hi_octane, Вы писали:

_>2) Многопоточность. После того как привыкнешь писать в immutable стиле и накидаешь основные примитивы макросами — C# вообще отдыхает. У нас к концу проекта основных примитивов многопоточности набралось штук наверное 20. В C# — lock в зубы, и остальное выписывай ручками в кренделя try/finally.


RX не годится ?

_>4) Задачи требующие своего DSL.


Покажи пример, пожалуйста.

_>5) Логгирование, замеры времени, особенно если проект в релизе, его как в C# не делай, всегда фигня будет получаться


Это инструментирование в рантайме или что ты имел ввиду ?

_>6) Задачи, которые на C# принято считать требующими кодогенераторов или отдельных программ. У нас например в процессе компиляции макрос лезет по сети и вытягивает оттуда JavaScript, а потом лезет по всему проекту, и в нужных местах корректирует код (не какие-то генерённые файлы обновляет, а разбирает и корректирует писанный людьми код), в соответствии с тем JavaScript. Чтобы такое повторить на C# — убиться надо.


А что за задачу вы решали таким образом ?

_>7) Даже самые простые вещи об которые спотыкается C#. Вот сделай мне чтобы прога при старте выводила дату/время компиляции и машину на которой билдилась, без посторонних приблуд и отдельных прог или там чек-сумму ключевых исходников посчитай


В TFS это делается достаточно просто Не пойму, зачем это надо не в релизной версии.

_>11) Генерировать что-то по коду проекта в процессе компиляции. Например javascript или базу данных. В C# БД генерировать умеет только наверное DevExpress XPO, и то через рефлексию и по рабочей программе а не во время компиляции. И со всякими ограничениями. В Nemerle можно в генерированную БД из бакапа например тестовые данные сразу вытягивать, если билд тестовый.


tt чем не подходит ?
Re[2]: Что лучше делать на Nemerle вместо C#
От: Darooma Россия  
Дата: 23.05.11 05:47
Оценка:
Здравствуйте, catbert, Вы писали:

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


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


C>Вряд ли. Но вполне возможно, что на Немерле можно намного проще и быстрее написать более эффективный алгоритм, чем на C#. Например, я хотел реализовать алгоритм


Это я и имел ввиду. Покажи, пожалуйств, код.
Re[3]: Что лучше делать на Nemerle вместо C#
От: Ziaw Россия  
Дата: 23.05.11 07:52
Оценка:
Здравствуйте, Darooma, Вы писали:

C>>Вряд ли. Но вполне возможно, что на Немерле можно намного проще и быстрее написать более эффективный алгоритм, чем на C#. Например, я хотел реализовать алгоритм


D>Это я и имел ввиду. Покажи, пожалуйств, код.


Посмотри на генератор парсеров PEG. Его алгоритмы эффективно более никто не реализовал, ибо нет удобных инструментов по анализу и генерации кода. Делать это на C#/Java/C++ никто в здравом уме даже не возьмется. Можно посмотреть на Antlr, сравнить количество приседаний для создания парсера на нем и быстродействие.

Посмотри примеры computatition expressions. Попробуй написать подобный код на C# до пятой версии, даже с rx это выглядит достаточно печально.

Посмотри на любой linq провайдер на C#, там Содом и Гоморра. Большинство их алгоритмов на nemerle могут быть сделаны гораздо понятнее и выразительнее.
Re[4]: Что лучше делать на Nemerle вместо C#
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.05.11 08:27
Оценка:
Здравствуйте, hi_octane, Вы писали:

_>Дата время есть. Проще всего из AssemblyInfo вытащить, можно из PE, наверняка есть и другие места. Но ты обрезал цитату рановато — там ещё было про имя билд-машины и чек-суммы ключевых исходников , а это уже фиг. У нас релиз клиенту отправлется только с одной машины, сбилженный человеком который лично всё два раза проверит, прежде чем собирать и отсылать. Если в качестве непланового багфикса какой-то левак и сбилдят — без большого красного свистка фиг запустится. Потому что цена ошибки высокая.


Сколько времени у вас уходит на один релилз ? Я про "сбилженный человеком который лично всё два раза проверит, прежде чем собирать и отсылать".
Re[2]: Что лучше делать на Nemerle вместо C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.05.11 09:53
Оценка:
Здравствуйте, hi_octane, Вы писали:

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

_>Оба языка на .NET, так что их быстродействие очень близко. В среднем, по слухам, код генерируемый на C# чуть быстрее.

Это домыслы. Если не прибегать к ансэйву, то результат примерно одинаковый.

_>4) Поддержка Linq, в C# Linq заинлайнен, сразу from и запрос. В Nemerle он мощнее, но приходится писать linq <# from .... #>. В Nemerle 2 исправят. Хотя имхо могли бы грязным хаком исправить и пораньше


В принципе у меня появились мысли о том как исправить это и в 1.х. Для этого парсить нужно с помощью PEG-а. Если найдутся добровольцы, готов изложить идею подробно.

_>6) То что некоторые фишки о которых и не подозреваешь, можно узнать только потусовавшись на форуме или случайно заметив в сорцах компилятора.


Тут комьюнити нужно быть по актинвее. Документация ведь в вики-формате. Каждый может ее дополнить, если заметил, что чего-то в ней нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Что лучше делать на Nemerle вместо C#
От: hi_octane Беларусь  
Дата: 23.05.11 10:01
Оценка:
VD>В принципе у меня появились мысли о том как исправить это и в 1.х. Для этого парсить нужно с помощью PEG-а. Если найдутся добровольцы, готов изложить идею подробно.
Да но при этом придётся же разломать и Lexer/ScanLexer, а также перелопатить пол подсветки синтаксиса, да?
Re[5]: Что лучше делать на Nemerle вместо C#
От: hi_octane Беларусь  
Дата: 23.05.11 10:27
Оценка:
I>Сколько времени у вас уходит на один релилз ? Я про "сбилженный человеком который лично всё два раза проверит, прежде чем собирать и отсылать".
Где-то неделя.

Тут бесполезно к чему-то цепляться. Есть проекты где цена ошибки стремится к стоимости времени её фикса. Например сайты-визитки. Там хоть пол-проекта разломай а клиенту зарелись билд который вообще от другого проекта — ну будет разговор вида "Чё там такое, вообще какая хрень! Посмотрите!" и всё. Там разработчики сами релизят то что у них на винчестере лежало, и это правильное решение. Есть проекты где цена ошибки немного повыше, например сутки простоя какой-нить большой команды из-за того что кто-то сломал всё совсем уже могут выйти очень дорого. Там внедряют всякие более-менее автоматические средства, те-же ночные тесты, и прочие. Разделяют на модули так чтобы лом чего-то одного не приводил к полной остановке всего, и это тоже правильное решение.

А если цена ошибки просто несравнима с з/п сотрудников, и вообще приближается к стоимости самого проекта, то тут выгодно хоть целый отдел нанять, который только и будет что билдить и тестировать, а билды клиенту под подпись самолётом возить, и это опять-таки правильное решение. Более того в каждом случае эти решения единственно правильные, потому что экономически наиболее эффективные.
Re[4]: Что лучше делать на Nemerle вместо C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.05.11 10:31
Оценка: 8 (1)
Здравствуйте, hi_octane, Вы писали:

VD>>В принципе у меня появились мысли о том как исправить это и в 1.х. Для этого парсить нужно с помощью PEG-а. Если найдутся добровольцы, готов изложить идею подробно.

_>Да но при этом придётся же разломать и Lexer/ScanLexer, а также перелопатить пол подсветки синтаксиса, да?

С подсветкой все будет по прежнему фигово. Но ломать ничего не придется. Идея в общем-то очень проста. Мы описываем макрос linq как лексерный (принимающий лексему — Token, а не PExpr). Далее, вместо того чтобы пытаться разобраться с лексемой мы тупо берем ее местоположение в файле, вынимаем код соответствующий ему и парсим его PegGrammor-ом. Те места которые должны соответствовать немерловым подвыражениям мы "вырезаем" как строки и скарливаем эти строки штатному парсеру немерла (можно даже выковырять под-лексемы).

В итоге, в добавок еще и код парсера упростится и станет декларативным.

Синтаксис линка при этом будет все же немного отличаться, так как перед запросом будет стоять ключевое слово linq, но все же это будет выглядеть лучше чем сейчас (не будет <# #>).

Можно попытаться обойтись и без linq. Для этого ключевым словом макроса надо сделать from. Но при этом from станет жестким ключевым словом видимым везде где открыто пространство имен с linq-макросом. В прочем, возможно это не такая большая проблема.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Что лучше делать на Nemerle вместо C#
От: Ziaw Россия  
Дата: 23.05.11 10:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>С подсветкой все будет по прежнему фигово. Но ломать ничего не придется. Идея в общем-то очень проста. Мы описываем макрос linq как лексерный (принимающий лексему — Token, а не PExpr). Далее, вместо того чтобы пытаться разобраться с лексемой мы тупо берем ее местоположение в файле, вынимаем код соответствующий ему и парсим его PegGrammor-ом. Те места которые должны соответствовать немерловым подвыражениям мы "вырезаем" как строки и скарливаем эти строки штатному парсеру немерла (можно даже выковырять под-лексемы).


Идея хорошая, а что парсер считает лексемой?
Re[5]: Что лучше делать на Nemerle вместо C#
От: Аноним  
Дата: 23.05.11 11:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>С подсветкой все будет по прежнему фигово. Но ломать ничего не придется. Идея в общем-то очень проста. Мы описываем макрос linq как лексерный (принимающий лексему — Token, а не PExpr). Далее, вместо того чтобы пытаться разобраться с лексемой мы тупо берем ее местоположение в файле, вынимаем код соответствующий ему и парсим его PegGrammor-ом. Те места которые должны соответствовать немерловым подвыражениям мы "вырезаем" как строки и скарливаем эти строки штатному парсеру немерла (можно даже выковырять под-лексемы).


А не разумнее ли будет сам штатный парсер на PEG переписать? Тогда и макросы проще станут, учитывая врожденную расширяемость PEG-ов.
Re[6]: Что лучше делать на Nemerle вместо C#
От: Ziaw Россия  
Дата: 23.05.11 12:14
Оценка:
Здравствуйте, Аноним, Вы писали:

А> А не разумнее ли будет сам штатный парсер на PEG переписать? Тогда и макросы проще станут, учитывая врожденную расширяемость PEG-ов.


как только эта самая расширяемость заработает )
Re[7]: Что лучше делать на Nemerle вместо C#
От: Аноним  
Дата: 23.05.11 12:24
Оценка:
Здравствуйте, Ziaw, Вы писали:

А>> А не разумнее ли будет сам штатный парсер на PEG переписать? Тогда и макросы проще станут, учитывая врожденную расширяемость PEG-ов.


Z>как только эта самая расширяемость заработает )


Ой. А она еще не работает? Пичалька. Я разочарован, как раз собирался в одном проекте это дело попробовать. Придется пока остаться с самописным packrat-ом на сишарпе.

А что там, собственно, такого сложного? Я не про наследование грамматик говорю, а про динамические расширения в заранее заданных точках.
Re[3]: Что лучше делать на Nemerle вместо C#
От: hi_octane Беларусь  
Дата: 23.05.11 12:39
Оценка: 33 (2)
_>>2) Многопоточность. После того как привыкнешь писать в immutable стиле и накидаешь основные примитивы макросами — C# вообще отдыхает. У нас к концу проекта основных примитивов многопоточности набралось штук наверное 20. В C# — lock в зубы, и остальное выписывай ручками в кренделя try/finally.

I>RX не годится ?

Ну когда мы заканчивали проект — Rx ещё не было Но даже если б и был — непредсказуемо тормозявый он. Причём его тормозявость — практически утверждена официально. А у нас жажда скорости прописана в ТЗ.

_>>4) Задачи требующие своего DSL.

I>Покажи пример, пожалуйста.
У клиента скрипт, скрипт он корректирует сам как ему захочется. Там по большей части Nemerle код, но формулы описаны чистой математикой, вроде SUM x * p1 * q1 DIV MAX x >= SUM y + a DISTINCT y = SUM b. И это не вызовы функций, эту запись мы вытягиваем как есть из исходника, немного правим, подставляем вместо параметров матрицы и скармливаем решателю вроде матлаба.

_>>5) Логгирование, замеры времени, особенно если проект в релизе, его как в C# не делай, всегда фигня будет получаться

I>Это инструментирование в рантайме или что ты имел ввиду ?
Да. Есть требование для некоторых функций уложиться в сколько сказали миллисекунд или здохнуть. Эдакий soft realtime. На этих функциях стоят аттрибутики, которые на самом деле макросы, которые перефигачивают код так, что если в релизе функция не вложилась в заданное число миллисекунд — сразу всю ситуацию в лог а прогу остановить. А если уложилась но подобралась к 90%, то просто в лог все операции с временами, для анализа. И чудо, у нас без профайлера (потому что его к реальной работающей проге просто не подключишь) с первых релизов есть гистограммы средней и пиковой нагрузки, и всё без замусоривания кода ручками, впихивания Stopwatch в try и Log в finally.

_>>6) Задачи, которые на C# принято считать требующими кодогенераторов или отдельных программ. У нас например в процессе компиляции макрос лезет по сети и вытягивает оттуда JavaScript, а потом лезет по всему проекту, и в нужных местах корректирует код (не какие-то генерённые файлы обновляет, а разбирает и корректирует писанный людьми код), в соответствии с тем JavaScript. Чтобы такое повторить на C# — убиться надо.

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

_>>7) Даже самые простые вещи об которые спотыкается C#. Вот сделай мне чтобы прога при старте выводила дату/время компиляции и машину на которой билдилась, без посторонних приблуд и отдельных прог или там чек-сумму ключевых исходников посчитай

I>В TFS это делается достаточно просто Не пойму, зачем это надо не в релизной версии.
Написал почему здесь
Автор: hi_octane
Дата: 23.05.11
.

_>>11) Генерировать что-то по коду проекта в процессе компиляции. Например javascript или базу данных. В C# БД генерировать умеет только наверное DevExpress XPO, и то через рефлексию и по рабочей программе а не во время компиляции. И со всякими ограничениями. В Nemerle можно в генерированную БД из бакапа например тестовые данные сразу вытягивать, если билд тестовый.


I>tt чем не подходит ?

Ну если сравнивать Nemerle и C#, то получается что эта внешняя тулза не C#. Да ещё самого убогого типа — т.е. тупо склейка строк по шаблону. Что там клеится и как проверяет программист глазками. Компилятор проверяет только синтаксическую корректность. Конечно когда ты связан по рукам и ногам ограничениями языка, в ход идёт всё. Вот пока не было linq — по всему миру люди клеили SQL ручками, бывало склеивали криво, что-то валилось, лезли назад и чинили. С linq проблема склейки ушла, и теперь гордые шарписты смотрят свысока на всех остальных. А сами втихую точно также склеивают C#-сорцы, вызывают пре-билд и пост-билд хреновины, и т.п. Но эти все убогости возникают от того что задачи решать хочется, а средств для их решения в C# нет.

Вот наглядный пример — реальный вопрос
Автор: Sinix
Дата: 15.02.11
, от одного из наиболее продвинуты тут людей. Сравни полученное решение на C# / T4
Автор: Sinix
Дата: 16.02.11
и решение на Nemerle
Автор: hardcase
Дата: 09.03.11
. Закономерное впечатление топикстартера:

Мдя, я предполагал, что будет короче и понятней, но не настолько же! Шикарно и спасибо


И это одна обычная задача. Два экрана на C# и один на Nemerle. Нужно ли говорить что на большом проекте разница уже не просто заметна, но начинает реально влиять не только на сроки, но и на реализуемость фич вообще?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.