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

ВВ>Есть и другие VM. Например, LLVM.

Опять языком чешешь. Ты попробуй на нем чего-то сделать. Это весьма низкоуровневое решение. Там сил нужно положить огого сколько.

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

G>Но другая. В F# есть набор методов в модуле Async, в C#5 норовят свести к TPL и дополнить его еще Dataflow, еще Rx с этим как-то работает.
G>А что будет в nemerle?

Почему будет? Есть. Аналог решения из F#. Только не вмонтированный в язык, а в виде макроса.
Вот тесты.

В C# 5 тоже будет хардкод в языке, но другой. Там реализация будет сделана на базе конечного автотама генерируемого для итераторов. Прерилиз доступен. Скачай, скомпилиру пример, и декомпельни. Там все очевидно.

G>>>я уже объяснял что тысячи разработчиков не будут изучать новые фреймворки.
VD>>Какие фрэймворки? Ты опять вещаешь о том в чем не удосужился разобраться?
G>Например классы компилятора для написания макросов.

Ты о чем? Выше тесты приведены. Где там эти мифические классы?

G>>>С вашим подходом к продвижению nemerle
VD>>Это что за подход? И что в нем не так?
G>Делать инструменты для делания инструментов для делания приложений.

Почему ты называешь библиотеки "инструментами для делания инструментов"?

G>Слишком большой путь от фичи до реального профита. Вместо рекламирования фич лучше бы показали профит от них.

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

G>>>в массы вы всегда будете в роли догоняющих и делать "круче, но другое" бессмысленно.
VD>>Догоняющих кого?
G>Тот же C# и даже полуисследовательский F#.

Ты совсем с реальностью связь потерял. Шарпу лет 20 развиваться, чтобы первый немерл догнать. F# по менее, но тоже не мало.

Короче, не выставляй себя ламером. Разберись в предмете обсуждения.

VD>>Пожалуй надо завершать эту "плодотворную" беседу, покая я не сорвался и не перешел на личности.
G>Нервы пора лечить.

Видимо. Общение с трепачами смело и без доли сомнения высказывающихся о том, что освоить не смогли сильно расшатывает нервы. Есть такое.

G>>>Я вообще сейчас SharePoint занимаюсь, мне не до Nemerle совсем.
VD>>Ну, ты занимайся SharePoint-ом дальше.
G>Ну вот кстати на Nemerle вполне можно было бы сделать code-first разработку для SharePoint, иначе приходится руками писать XML определения типов контента. На T4 такое делается крайне плохо, на нем тяжело анализировать код решения.

Не, ребят. Шарыпоинты и 1С-ы, это вы сами как-нить.

VD>>Еще 1С хорошее занятие.
G>Ну 1c не я занимаюсь. Но вот кажись именно в этой теме некоторые люди пиарили макросы как средство работы с внешними системами, почему бы не написать ченить для работы с 1С?

Жалко свой интеллект. Да и есть чем заняться.

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

WH>>Простите не поверю.
WH>>Ибо моя практика говорит что ничего подобного нет.

DG>тебе просто повезло и ты очень умный. остальные, к сожалению, не такие...

Как не повезло этим остальным.

ЗЫ

Попробуй, все же то о чем говоришь на практике (не свой самопал, а то о чем говришь).
Готов помочь тебе разобраться с тем, что ты не понял.

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

K>По этому никто, кроме вас, не знает как оно работает и вообще, существует ли в природе? :-D
K>Уже пару гневынх пстов о "хорошей" документации великого и ужасного было

Как показывают этюды Никова — это в C# никто (кроме Никова) не знает как он работает .

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

G>>Вот nemerle эту проблему решает, но его макры работают только для nemerle.
WH>Другие .NET языки не нужны.
WH>Хотя C++/CLI может пригодится для жестокого интеропа с жестоким легаси.

На самом деле все это могло бы жить и в рамках массы языков. Сделал же МС рантайм для разных языков?

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

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

Кэр>Это как бы не нуждается в напоминании. Я только утверждаю, что идей действительно достойных нового языка не так уж много. И людей способных достойно эти идеи воплотить тоже. Иначе мы бы уже имели популярный язык для .Net, который решает твой вопрос, innit? Любую фичу можно использовать как во благо, так и во вред. Мне вот такое свободное изменение синтаксиса дает такую картину перекрестного опыления различными библиотеками результирующего кода, что жить не хочется. Представь, что ты хочешь заюзать либу для XML разработанной третьей стороной. А она заодно тебе привозит переопределение $, % и неровно дышит к наличию < > в коде. Что наступает на уши либе по обработке HTML, которая разработана yet another third party. И вдобавок это все конфликтует с кодом, который местный сениор отчаянно колбасил еще в самом начале проекта, изголяясь во все стороны и под разными углами. И сидишь ты и чешешь репу, как бы разодрать все эти либы в разные стороны, чтобы синтаксис наконец-то стал однозначным. И при чтении разных файлов тебе приходится вспоминать, а что означает вот этот keyword и вот этот символ в этом контексте.

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

Та же байда и с макрами. Если два макроса претендуют на один синтаксис, то они просто не скомпилируются в рамках одного файла.

Кэр>Я скажу сразу — нах такое не нужно. Пока не показано, как эта проблема будет решена — я категорически против подобных завихрений в моих проектах.

А я скажу другое. Трепачи всегда были находками для шпиёнов. Больше от них толку не было ни когда. Вот и ты из этого числа. Сам ничего не пробовал, но мнение имеешь. Толку от твоего мнения не больше, чем от мнения бабки с базара.

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


VD>>Кстати, объясни общественности какое отношение суперкомпиляция имеет к метапрограммированию?

DG>если исходить из определений, то самое непосредственное.
DG>суперкомпиляция — это подвид метапрограммирования.

DG>

DG>Метапрограммирование — вид программирования, связанный с созданием программ, которые порождают другие программы как результат своей работы

DG>

DG>Суперкомпиляция — специальная техника оптимизации алгоритмов, основанная на знании конкретных входных данных алгоритма.

Больше вопросов нет. Еще один слив успешно засчитан! Так держать!

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

G>>>>в массы вы всегда будете в роли догоняющих и делать "круче, но другое" бессмысленно.
VD>>>Догоняющих кого?
G>>Тот же C# и даже полуисследовательский F#.

VD>Ты совсем с реальностью связь потерял. Шарпу лет 20 развиваться, чтобы первый немерл догнать. F# по менее, но тоже не мало.
Тем не менее на F# пишет больше народу, чем на Nemerle.
Наверное потому что плохой язык, да.

VD>Короче, не выставляй себя ламером. Разберись в предмете обсуждения.
От этого больше народу начнет пользоваться Nemerle? или там появятся Type Providers? Или yield в нем перестанет быть хардкодом?

Ты огрзаешься вместо того чтобы попытаться увидеть проблемы. И вспоминать Блаб тут неуместно, хаскели, nemerle и F# находятся примерно на одном уровне блабнутости.

DG>>

DG>>Метапрограммирование — вид программирования, связанный с созданием программ, которые порождают другие программы как результат своей работы

DG>>

DG>>Суперкомпиляция — специальная техника оптимизации алгоритмов, основанная на знании конкретных входных данных алгоритма.

с каких это пор программа перестала быть видом записи алгоритма?

может тебе все-таки стоит почитать хотя бы книжку "теория программирования для маленьких"?
а то я вижу, что с основами теоретии программирования — у тебя швах.

кстати, макросы (раскрытие и свертку), исходя из теории программирования можно рассматривать, как подвид суперкомпиляции программы.

при этом фиксированным доп. параметром суперкомпиляции — является исполнитель: с одной стороны — компилятор конкретного языка, с другой стороны — разработчик.
улучшаемые показатели — компактность, понятность.

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


DG>>>

DG>>>Метапрограммирование — вид программирования, связанный с созданием программ, которые порождают другие программы как результат своей работы

DG>>>

DG>>>Суперкомпиляция — специальная техника оптимизации алгоритмов, основанная на знании конкретных входных данных алгоритма.

DG>с каких это пор программа перестала быть видом записи алгоритма?

А к чему этот вопрос?

Ты не в состоянии отличить метода оптимизации от средства программирования. Вот в этом и вопрос.

К тому же лезешь рассуждать о весьма хитрых вещах даже не понимая их азов.

То как действует супер-компиляция плохо понимают даже такие люди как авторы хаскеля. На практике они практически не использовались. Только в Рефале — языке чисто эксперементаторском. А ты лезешь даже в такие непростое области.
Супер-компилятор не просто переписывает код по какому-то там алгоритму. Он создает мета-модель кода и производит частичные вычисления. При этом никаких новых результатов не получается. Получается всего лишь более шустрый код для той же самой программы.

Другими словами в суперкомпиляции присутствует "мета", но не присутствует программирования, так как никаких новых программ не создается. Мета-программирвоание же своей целью несет порождение или изменение имеющихся программ (изменение их семантики!).

Так что слова "если уж говорить о МП — то стоит говорить о суперкомпозиции кода и о суперкомпиляции, а не о макросах" — это полнейший лам, так как никакой связи между МП и суперкомпозицией нет. Это совершенно разные задачи.

DG>может тебе все-таки стоит почитать хотя бы книжку "теория программирования для маленьких"?
DG>а то я вижу, что с основами теоретии программирования — у тебя швах.

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

ЗЫ

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

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

VD>>Ты совсем с реальностью связь потерял. Шарпу лет 20 развиваться, чтобы первый немерл догнать. F# по менее, но тоже не мало.
G>Тем не менее на F# пишет больше народу, чем на Nemerle.

Алё! Ты еще и с логикой не дружишь? Где связь между возможнсотями языка и тем сколько людей на нем пишут. Скажем на PHP пишет раз в 100 больше чем на F#. Можно из этого сделать вывод, что F# не дорос до PHP?

Или ты живешь по принципу — "Миллионы мух не могут ошибиться!"?

G>Наверное потому что плохой язык, да.

Ты про этот язык тоже на форуме прочитал?
У F# есть только одно, весьма спорное, преимущество — глобальный вывод типов. Во всем остальном он <= Nemerle. Отсутствие макросистемы (при наличии, кстати, квази-цитирования необходимого для макросов) уже делает F# языком гораздо менее мощным. Функциональные возможности у языков почти идентичные. ООП в F# несравнимо хуже. Куча проблем вроде необходимости размещения файлов в проекте в определенном порядке и невозможность создать папку в которую поместить часть кода. При этом та же интеграция с IDE не в пример слабее. Все что сделано в F# или уже есть в немерле, или реализовано в виде макросов. Так как же F# может быть лучше?

Ну, а пишут на нем может и по более. Только заслуга тут исключительно в том ярлыке "Под покровительством Майкрософт". Ни одного реального достоинства у F# перед немерлом нет. И это факт, а не чьи-то домыслы.

VD>>Короче, не выставляй себя ламером. Разберись в предмете обсуждения.
G>От этого больше народу начнет пользоваться Nemerle?

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

G> или там появятся Type Providers? Или yield в нем перестанет быть хардкодом?

Тебя заело? Про Type Providers тебе уже раз 20 ответили.
Где, кстати, yield в F#?

G>Ты огрзаешься вместо того чтобы попытаться увидеть проблемы.

Проема тут только над. Ты и твое алогичено мышление. Ты вместо того чтобы попробовать то что хаишь несешь чушь и что-то пытаемый доказать применяя "аргумент" про миллионы мух.

G>И вспоминать Блаб тут неуместно, хаскели, nemerle и F# находятся примерно на одном уровне блабнутости.

Чтобы судить об этом тебе все это надо изучить. Хотя бы поверхностно. А ты судишь о вещах лежащих вне твоей компетенции на базе опыта C#-программиста. Это все равно как рассуждать о космических аппаратах на базе знаний тракториста. Это уже не парадокс Блаба. Это уже по чище. Это воинствующие невежество. Уж извини за прямоту. Достал ты не на шутку.

ЗЫ

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

Всем идущим ровными рядами к светлому будущему — счастливой дороги!

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

DG>кстати, макросы (раскрытие и свертку), исходя из теории программирования можно рассматривать, как подвид суперкомпиляции программы.

Что за свертку макросов ты сейчас придумал?

Что до суперкомпиляции, то еще раз повторяю тебе — это метод оптимизации. Она не меняет семантики кода. МП же своей целю имеет изменение семантики.

Ты лучше овтеть на прсотой вопрос. С какой целью ты суперкомпиляцию сюда приплел (если, кончено, отбросить предположение, что брякнул не подумав)?

DG>при этом фиксированным доп. параметром суперкомпиляции — является исполнитель: с одной стороны — компилятор конкретного языка, с другой стороны — разработчик.

О, блин, дожили. Разработчик стал у нас параметром программы!

DG>улучшаемые показатели — компактность, понятность.

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

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

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

S>>Бенефит в том, чтобы одна команда могла заниматься dynamic, а другая команда параллельно и независимо могла заниматься async.
G>То есть макры — не тул для программистов, а тул для разработчиков компилятора.
Фактически — да. У меня по-прежнему нет личного опыта, но всё выглядит именно так. Придумать и реализовать макру уровня dynamic может далеко не всякий. Большинство из того, что доступно рядовому разработчику типа меня, реализуется в традиционных функциях. Т.е. максимум — это более чистый синтаксис для достаточно тривиальных вещей.

G>А вот на примере Nemerle это видно плохо. Потому что основная проблема при разработке языка — далеко не реализовать некоторые конструкции. А понять как они должны работать. Липперт пишет огромные посты, которые касаются только выбора синтаксиса для yield и\или async, совершенно не касаясь семантики, и даже реализации.
А мне казалось, что он как раз пишет в основном о семантике. Вопросы выбора синтаксиса, имхо, далеко не так важны.

G>С другой стороны есть немалая область, неподвластная сейчас C#\Visual Studio — compie-time rewriting. Те же code contracts реврайтятся отельными утилитами, для статического AOP используется PostSharp, который тоже реврайтит отдельным процессом.
Ну это как раз от того, что в языке средств нету.

G>Вот nemerle эту проблему решает, но его макры работают только для nemerle.
Угу.

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

Кэр>Await/async покрываются пятой версией шарпа...
Это понятно. В теории (я не силён в немерле) макросы позволяют сделать await/async. В отличие от собственно тайп провайдеров.

Кэр>Это как бы не нуждается в напоминании. Я только утверждаю, что идей действительно достойных нового языка не так уж много. И людей способных достойно эти идеи воплотить тоже.
Ну, пока что их хватило на выпуск ажно пяти версий шарпа, и, если верить блогу Липперта, у них ещё втрое больше лежит в бэклоге потому что не хватает ресурсов на реализацию.
>Иначе мы бы уже имели популярный язык для .Net, который решает твой вопрос, innit?
Хм. Чем-то эта фраза похожа на "если бы это было нужно, то это бы уже сделал microsoft"
Мы же всё-таки тренируем критическое мышление

Кэр>Любую фичу можно использовать как во благо, так и во вред. Мне вот такое свободное изменение синтаксиса дает такую картину перекрестного опыления различными библиотеками результирующего кода, что жить не хочется.
Ну, это старый аргумент. Я наблюдаю этот спор тут чуть ли не со времён R#. Ответы на него мне тоже известны.
Как оно окажется на практике — пока что непонятно. Пока что мы имеем не очень много макросных библиотек для немерле, так что трудно сказать, насколько твой страх оправдан.

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

Кэр>Прототипировать — сколько угодно. Nemerle на самом деле дальше прототипа и не ускакал.


S>>Основной бенефит даже не в том, чтобы не трогать компилятор — с точки зрения пользователя нет разницы, откуда взялся async.
S>>Бенефит в том, чтобы одна команда могла заниматься dynamic, а другая команда параллельно и независимо могла заниматься async. Это позволяет масштабировать скорость разработки языка.

Кэр>С точки зрения прототипирования — бенефит вполне ощутим и очень крут. С точки зрения разработки — цена за эти бенефиты несоозмерима.
Ну, пока что у нас нет никакой статистики для определения этой цены.

Впрочем, мы отклонились от темы. Вопрос же был не в том, лучше ли Nemerle чем C#. Вопрос был "зачем нужны макросы, когда есть type providers". Я своё мнение на эту тему высказал. Стоят ли эти бенефиты недостатков или нет — вопрос отдельный.

Всегда будут люди, которым важнее наличие у языка поддержки стабильной компании важнее, чем какие бы то ни было конкретные фичи.
Await/async, реализованный в Nemerle, для таких людей всегда будет хуже, чем await/async, реализованный в C#.
Аудитория Nemerle — всё же люди, которым наличие таких фич в языке важнее, чем одобрение авторитетов компайлеростроения.

Здравствуйте, VladD2, Вы писали:
VD>Супер-компилятор не просто переписывает код по какому-то там алгоритму. Он создает мета-модель кода и производит частичные вычисления. При этом никаких новых результатов не получается. Получается всего лишь более шустрый код для той же самой программы.

VD>Другими словами в суперкомпиляции присутствует "мета", но не присутствует программирования, так как никаких новых программ не создается. Мета-программирвоание же своей целью несет порождение или изменение имеющихся программ (изменение их семантики!).
Вот тут, имхо, ты не прав. Суперкомпиляция всё же порождает новую программу, которая семантически эквивалентна исходной, но в более узкой области определения входных параметров.
Это всего лишь другая ветка метапрограммирования.

Здравствуйте, Воронков Василий, Вы писали:
ограничивать.

ВВ>Проблема, как я сказал, не в том, что джаваскрипт, а в том, что присутствует само разделение на клиент и сервер, которое как правило не совпадает с логическим разделением приложения на лаеры. В итоге получается, что код решающий одни и те же задачи (скажем, генерацию пользовательского интерфейса) пишется и на сервере, и на клиенте, на разных языках, с использованием разных подходов. Вот это, мне кажется, — проблема. А сколько там строк кода надо для описания модели — по-моему достаточно по фиг. Как и то, какая там используется типизация в ДАЛе.
Есть разные способы разделения; не при всех выполняется значительное дублирование.
Для некоторых частных случаев (например — валидация данных) метапрограммирование как раз позволяет построить компилятор с одного языка в несколько бэк-ендов:
— в SQL, чтобы оптимизатор запросов мог пользоваться semantic query optimizaiton
— в серверный код (например MSIL), чтобы нельзя было подсунуть некорректные данные в API
— в JavaScript, чтобы можно было выполнять валидацию без похода на сервер.

В общем случае я не вижу способа сделать компиляцию Nemerle-кода в JS. По крайней мере, в эффективный JS.

ВВ>Например, одно полноценное и отработанное на практике решение этой проблемы — писать все на ДжаваСкрипте на клиенте Серверная часть при этом становится тонкой и занимается лишь тем, что возвращает на клиент данные в виде ХМЛ-я или Джейсона. Роль языка, на котором эта серверная часть пишется, как ты понимаешь, весьма серьезно падает.
Не вижу никакого падения роли серверного языка.
Даже "толстый" JS-клиент работает не в вакууме. Фактически, имеем клиент-серверное приложение. API сервера для него весьма и весьма важен, т.к. именно он определяет возможности клиента. На первый план выступает REST и прочее.
Статика тут позволяет опять же гарантировать ссылочную корректность (к примеру, что JavaScript код не пытается обращаться к несуществующим точкам входа) и много других полезных вещей.

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

Кэр>Это как бы не нуждается в напоминании. Я только утверждаю, что идей действительно достойных нового языка не так уж много. И людей способных достойно эти идеи воплотить тоже. Иначе мы бы уже имели популярный язык для .Net, который решает твой вопрос, innit? Любую фичу можно использовать как во благо, так и во вред. Мне вот такое свободное изменение синтаксиса дает такую картину перекрестного опыления различными библиотеками результирующего кода, что жить не хочется. Представь, что ты хочешь заюзать либу для XML разработанной третьей стороной. А она заодно тебе привозит переопределение $, % и неровно дышит к наличию < > в коде. Что наступает на уши либе по обработке HTML, которая разработана yet another third party. И вдобавок это все конфликтует с кодом, который местный сениор отчаянно колбасил еще в самом начале проекта, изголяясь во все стороны и под разными углами. И сидишь ты и чешешь репу, как бы разодрать все эти либы в разные стороны, чтобы синтаксис наконец-то стал однозначным. И при чтении разных файлов тебе приходится вспоминать, а что означает вот этот keyword и вот этот символ в этом контексте.

Вменяемый разработчик не станет делать "переопределение $, % и неровно дышит к наличию < > в коде", как сейчас не делают екстеншены с сигнатурой IEnumerable<T> First<T>(Func<T,bool> predicate). В первом случае это будет вести к конфликтам с семантикой кода, во втором со стандартной библиотекой.

ДСЛ обычно прячется в какой-то блок кода, если внутри этого блока используются выражения на базовом языке, то они чаще всего интерпретируются as is.

Давай на примере джейсона:

    def test = json({ 
      a : arr; 
      b : obj; 
      c : null;
      d : true;
      e : { a : 1; "la la": null};
      "f" : [true];
      j : (43 + 55);
    });

В теории он переопределяет значение оператора уточнения типа ":", на практике это никаких проблем в понимании кода не вызывает (по крайней мере у тех, кто знает что такое джейсон). Он не переопределяет ":" глобально, просто при разборе кода внутри себя интерпретирует его по своему.

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

    def strObj = "test";
    def test = json({ 
      j : (strObj : string);
    });

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

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

S>В общем случае я не вижу способа сделать компиляцию Nemerle-кода в JS. По крайней мере, в эффективный JS.

Кстати, а какие основные проблемы ты тут видишь? C# же компилируют в js?

Я вижу основную проблему в том, что хорошо зная js, обязательно захочется делать трюки обычные для js, но невозможные для nemerle.

Примерна та же проблема была у ранних ORM со своим языком запросов, который был богат, но не являлся заменой SQL тому, кто использовал нетривиальные запросы, не говоря уже об особенностях серверов.

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

S>Здравствуйте, Кэр, Вы писали:

Кэр>>Await/async покрываются пятой версией шарпа...
S>Это понятно. В теории (я не силён в немерле) макросы позволяют сделать await/async. В отличие от собственно тайп провайдеров.

С учетом того, что type provider решают задачу типизации нетипизированных данных, то это прямо удивительно, что они не решают проблему await/async. Хм...

Кэр>>Это как бы не нуждается в напоминании. Я только утверждаю, что идей действительно достойных нового языка не так уж много. И людей способных достойно эти идеи воплотить тоже.
S>Ну, пока что их хватило на выпуск ажно пяти версий шарпа, и, если верить блогу Липперта, у них ещё втрое больше лежит в бэклоге потому что не хватает ресурсов на реализацию.
>>Иначе мы бы уже имели популярный язык для .Net, который решает твой вопрос, innit?
S>Хм. Чем-то эта фраза похожа на "если бы это было нужно, то это бы уже сделал microsoft"
S>Мы же всё-таки тренируем критическое мышление

А языки теперь разрабатывает только Микрософт? Макросы и кастомный синтаксис далеко не Немерле придумал. Концепт давний и имеют большую историю быть непопулярным. Предлагаю в качестве упражнения по критическому мышлению подумать почему.

Кэр>>Любую фичу можно использовать как во благо, так и во вред. Мне вот такое свободное изменение синтаксиса дает такую картину перекрестного опыления различными библиотеками результирующего кода, что жить не хочется.
S>Ну, это старый аргумент. Я наблюдаю этот спор тут чуть ли не со времён R#. Ответы на него мне тоже известны.
S>Как оно окажется на практике — пока что непонятно. Пока что мы имеем не очень много макросных библиотек для немерле, так что трудно сказать, насколько твой страх оправдан.

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

Кэр>>Я скажу сразу — нах такое не нужно. Пока не показано, как эта проблема будет решена — я категорически против подобных завихрений в моих проектах.
S>Пока нужно доказать наличие проблемы

Кому надо? Я сказал свои критерии. И сказал, почему их не будет в моих проектах. Все остальные могут прототипировать наздоровье. Кто мешает?

Кэр>>Прототипировать — сколько угодно. Nemerle на самом деле дальше прототипа и не ускакал.
S>

А ну да. Это уже полноценная замена шарпа. Извините, опять забыл

S>>>Основной бенефит даже не в том, чтобы не трогать компилятор — с точки зрения пользователя нет разницы, откуда взялся async.
S>>>Бенефит в том, чтобы одна команда могла заниматься dynamic, а другая команда параллельно и независимо могла заниматься async. Это позволяет масштабировать скорость разработки языка.

Кэр>>С точки зрения прототипирования — бенефит вполне ощутим и очень крут. С точки зрения разработки — цена за эти бенефиты несоозмерима.
S>Ну, пока что у нас нет никакой статистики для определения этой цены.

Everyone is welcome to try. Everyone else, of course.

S>Впрочем, мы отклонились от темы. Вопрос же был не в том, лучше ли Nemerle чем C#. Вопрос был "зачем нужны макросы, когда есть type providers". Я своё мнение на эту тему высказал. Стоят ли эти бенефиты недостатков или нет — вопрос отдельный.

S>Всегда будут люди, которым важнее наличие у языка поддержки стабильной компании важнее, чем какие бы то ни было конкретные фичи.
S>Await/async, реализованный в Nemerle, для таких людей всегда будет хуже, чем await/async, реализованный в C#.
S>Аудитория Nemerle — всё же люди, которым наличие таких фич в языке важнее, чем одобрение авторитетов компайлеростроения.

Ага. И именно эту аудиторию все никак не удается нащупать.