Здравствуйте, 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 — всё же люди, которым наличие таких фич в языке важнее, чем одобрение авторитетов компайлеростроения.

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