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

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

G>>Самое забавно что я уже освоил nemerle на уровне написания кода, но:

VD>Ой не зарекайся. Я и через 3 года активного программирования открывал для себя много нового.

G>>1)По сравнению с C# не хватает тулинга
VD>Туллинг — это круто! А по русски?
Различные инструменты для работы с кодом
1)Поддержка студии 2010
2)рефлектор
3)решарпер
4)сниппеты
5)работа в silverlight
6)работа в SQL CLR

Да и тупо 98% примеров кода на .NET идут на C#

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

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

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

G>>>Самое забавно что я уже освоил nemerle на уровне написания кода, но:

VD>>Ой не зарекайся. Я и через 3 года активного программирования открывал для себя много нового.

G>>>1)По сравнению с C# не хватает тулинга
VD>>Туллинг — это круто! А по русски?
G>Различные инструменты для работы с кодом
G>1)Поддержка студии 2010
G>2)рефлектор
G>4)сниппеты
G>6)работа в SQL CLR

Вот это:
G>3)решарпер
G>5)работа в silverlight
конечно недостаток. В остальном же требования явно высосаны из пальца.
Зафиг тебе более одной IDE? Рефлектор в 90% случаев декомпилирует код в C#.


G>Да и тупо 98% примеров кода на .NET идут на C#

А что ты не в силах их воспроизвести с другим синтаксисом?

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

Кэр>С учетом того, что type provider решают задачу типизации нетипизированных данных, то это прямо удивительно, что они не решают проблему await/async. Хм...
Я не пытаюсь кого-то удивить.
Напомню ещё раз — вот вопрос:

Вполне возможно, что это решается через type providers о которых говорил Don Syme на PDC.
Это решение потенциально покрывает такой пласт проблем, что возникает большой вопрос — а зачем тогда нужны будут макросы.

Я отвечаю на этот вопрос. А не пытаюсь указать на какие-то недостатки в тайп провайдерах.

Кэр>А языки теперь разрабатывает только Микрософт? Макросы и кастомный синтаксис далеко не Немерле придумал. Концепт давний и имеют большую историю быть непопулярным. Предлагаю в качестве упражнения по критическому мышлению подумать почему.
Ну, как сказать. Некоторые макросы (к примеру те, которые в препроцессоре C/C++) популярнее, скажем, чем linq и dynamic вместе взятые.

Обсуждение проблемы совместимости синтаксисов я поскипал.

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

Кэр>>С учетом того, что type provider решают задачу типизации нетипизированных данных, то это прямо удивительно, что они не решают проблему await/async. Хм...
S>Я не пытаюсь кого-то удивить.
S>Напомню ещё раз — вот вопрос:
S>

S>Вполне возможно, что это решается через type providers о которых говорил Don Syme на PDC.
S>Это решение потенциально покрывает такой пласт проблем, что возникает большой вопрос — а зачем тогда нужны будут макросы.

S>Я отвечаю на этот вопрос. А не пытаюсь указать на какие-то недостатки в тайп провайдерах.

А ты давишь на то, что с помощью макросов надо дизайнить await/async.

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

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

Тот же Немерле несмотря на заверения, что ну теперь-то создать новый язык ну ваааааще просто — не принес новых концептов. Пока подбираются концепты из других языков и реализуются. Не видно пока, как Немерле бежит впереди шарпа. Где же power unleashed? Все эти фыркания, что мол type providers можно реализовать в Nemerle очень просто — они дорого не стоят. Для начала надо показать, кому Немерле нужен in the first place.

String format который делает захват локальных переменных — это прикольно. Но не более. Такими фишками новый язык не продать.

Кэр>>А языки теперь разрабатывает только Микрософт? Макросы и кастомный синтаксис далеко не Немерле придумал. Концепт давний и имеют большую историю быть непопулярным. Предлагаю в качестве упражнения по критическому мышлению подумать почему.
S>Ну, как сказать. Некоторые макросы (к примеру те, которые в препроцессоре C/C++) популярнее, скажем, чем linq и dynamic вместе взятые.

Спорно, но допустим. Как отсюда возьмется аудитория для Немерле? Ты пытаешься сказать, что препроцессорными директивами в плюсах какая-то видимая часть аудитории пытается создать новый язык?

S>Обсуждение проблемы совместимости синтаксисов я поскипал.

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

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

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

+1. Кстати, в 2010 студии появился пекедж менеджер. Это дает установку немерла в 2 клика прямо из студии. Но 2010 надо поддержать, как ни крути, пусть простейшую интеграцию, без сенса и прочего.

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

DG>в текстовых терминах проще формулировать утверждения.
DG>если рассматривать МП не в текстовых терминов — то там слишком много незнакомых терминов надо вводить.

Это каких же? Что-то я не заметил, что ты скромен в количестве термиинов. Той же семантики навалил целую кучу и в тему и не в тему.

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

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

А от тебя я все еще жду реальные примеры применения МП. Ведь у тебя множество исследовательских проектов применяющих МП. Не обязательно код, у тебя же наверняка NDA Просто проблема, способ решения.

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

ВВ>>Тогда не очень понял, что это за стратегии. Примерчик можно?
S>Я же приводил. Пишем констреинт на свойство; этот констреинт компилируется в DDL, в JS, и в MSIL.
S>Кода по построению UI нет в сервере, кода по работе с разделяемым состоянием нет в JS.

Ну т.е. у тебя идет все та же трансляция в JS, только в более ограниченном объеме. Я, честно говоря, с трудом вижу тут альтернативу компилятору некоего "нашего" языка в JS — скорее это другой подход к реализации, более проблемно-ориентированный что ли.

ВВ>>Заметь, кстати, ты сравнил Си и ASP.NET MVC, т.е. корову и яйца. А не Си и C#. Т.е. что тебе упрощает твой РЕСТ-то на самом деле? Не язык, нет. Библиотека.
S>А на C ASP.NET MVC написать невозможно. Нет в языке средств по построению таких "библиотек". Иначе бы С++ так никогда и не родился бы.

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

ВВ>>Я таких средств не знаю. Linq к ним не относится, к примеру.
S>Почему? По-моему, он таки как раз относится. Банально то, что он реализует пейджинг из коробки, уже решает очень многое. Потому что на более традиционных фреймворках программисты тупо на это забивают и делают skip/take в серверном коде. Проблемы с масштабируемостью такого подхода очевидны?

Ну если с таких позиций подходить — то да, эффективный. Я под эффективностью понимаю как раз хорошую масштабируемость — какими бы ни были объемы данных и сложность запросов, linq должен быть реальной альтернативной рукописным запросам. Но это в реальности не так. Да и не может быть так, ибо он слишком высокоуровневый по сравнению с конкретным диалектом SQL.
Но да, если программисты не умеют делать пейджинг и лепять skip/take, то linq может стать даже этаким средством оптимизации.

ВВ>>Кстати, такие средства даже на уровне, скажем, C# кода вносят такой оверхед, что мало не покажется. Представляешь же как linq2sql работает? Не будешь же ты предлагать отказаться от него только потому что он пессимизирует скорость C# кода?
S>Он оптимизирует скорость SQL кода. Это гораздо лучше.

Да не оптимизируют они. Разве что по сравнению с очень плохим SQL. Любой программист, имеющий хотя бы базовые знания конкретного диалекта SQL, напишет запросы, которые по крайней мере не медленнее.

ВВ>>Мне, честно говоря, не особо знакома эта проблема. И совсем не знакомо рекламируемое тобой решение. Если ссылки генерятся с помощью какого-то механизма, то наверное нам уже все равно, на каком языке там код на сервере?
S>Не на всех языках можно сгенерировать такой код. На шарпе есть метаданные обо всём: мы можем передать в генератор типизированный делегат, который гарантированно резолвится в нужный нам метод. А можем и прямо конкретный вызов передать — при помощи лямбды. Мне не очень понятно, как это же сделать на языке, где нет понятий о типах.
ВВ>>На худой конец — парсер JS + валидатор ссылок, которые можно тупо натравить на исходники и получить результат, должны решить эту проблему чуть более чем полностью и без всякой статической типизации.
S>Хм. Каким образом предполагается валидировать ссылки?

Я, видимо, все же не понимаю проблему. Какого рода ссылки предполагается проверять? Банальный способ проверки ссылки — ну сделать HEAD запрос, скажем. Или имеется в виду механизм, который сможет проверить, что GET /products/5 — это валидно, а вот GET /products/7 — уже невалидно, ибо продукта с ид 7 у нас нет?

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

ВВ>Ну т.е. у тебя идет все та же трансляция в JS, только в более ограниченном объеме. Я, честно говоря, с трудом вижу тут альтернативу компилятору некоего "нашего" языка в JS — скорее это другой подход к реализации, более проблемно-ориентированный что ли.
да.

ВВ>Не знаю, не уверен. По идее все, что нам может на Си помешать реализовать АСП.НЕТ MVC — будет мешать и в Си++.
Какая-то вывернутая логика. Мешать нам ничто не мешает. Вопрос в том, что нам помогает.
Если в языке нет понятия "типизированный указатель на функцию", то нам ничто уже не поможет его эмулировать — только рукопашный код, без какой-либо поддержки компилятором.

ВВ>Но Си это все же язык, который создавался задолго до эпохи веб. А на любом более или менее современном языке, включая динамические скрипты, фреймворк соответствующий возможностям MVC реализуем. Даже наоборот — это на C# затруднительно сделать что-либо вроде РубиОнРаилс.
Возможно. Я весьма поверхностно знаком с рельсой.


ВВ>Да не оптимизируют они. Разве что по сравнению с очень плохим SQL. Любой программист, имеющий хотя бы базовые знания конкретного диалекта SQL, напишет запросы, которые по крайней мере не медленнее.
Это иллюзия. На практике запросов гораздо больше, чем программистов. Корректно реализовать динамическое построение запроса может не всякий — это я тебе на личном опыте говорю. Я приводил примитивные примеры. Даже их народ реализовывать не хочет — пишут сплошь и рядом ((Age >= @MinAge) OR (@MinAge is null)). Что, естественно, убивает производительность.

А если мы попробуем состряпать что-то мало-мальски динамичное с использованием star join, то будет полный туши свет.
Я этого кода, написанного "любым программистом", наотлаживался в начале 2000х по самые помидоры. Все эти чудесные sqlstring1, sqlstring2, взаимонеисключающие if-ы... И всё это в части corner cases падает, а в другой части — почти работает, только данные выдаёт не те.

А если мы попробуем внести любой рефакторинг — ну там, колонку добавить, или переименовать, или убрать — всё, копец. Ты остаёшься один на один с тоннами кода, по которому даже контекстный поиск не сделаешь, потому что умники там понаписали всякого типа "where date" & dateType &" = @dateParam1".
Вот тут линк должен очень-очень сильно помочь.

ВВ>Я, видимо, все же не понимаю проблему. Какого рода ссылки предполагается проверять? Банальный способ проверки ссылки — ну сделать HEAD запрос, скажем. Или имеется в виду механизм, который сможет проверить, что GET /products/5 — это валидно, а вот GET /products/7 — уже невалидно, ибо продукта с ид 7 у нас нет?
Имеется в виду механизм, который поймёт, что у нас вообще бывают ссылки на /products/xx. Который отловит, что нигде нет опечатки типа /product/xx. И что никто не использует старый формат products?id=xx.

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

Здравствуйте, Кэр, Вы писали:
Кэр>А ты давишь на то, что с помощью макросов надо дизайнить await/async.
Ага.

Кэр>Тот же Немерле несмотря на заверения, что ну теперь-то создать новый язык ну ваааааще просто — не принес новых концептов. Пока подбираются концепты из других языков и реализуются. Не видно пока, как Немерле бежит впереди шарпа. Где же power unleashed? Все эти фыркания, что мол type providers можно реализовать в Nemerle очень просто — они дорого не стоят. Для начала надо показать, кому Немерле нужен in the first place.

Кэр>String format который делает захват локальных переменных — это прикольно. Но не более. Такими фишками новый язык не продать.
Это верно. "От него кровопролитие ждали, а он чижика съел".

Кэр>Спорно, но допустим. Как отсюда возьмется аудитория для Немерле? Ты пытаешься сказать, что препроцессорными директивами в плюсах какая-то видимая часть аудитории пытается создать новый язык?
Конечно! Наивно этого не видеть. Посмотри на тот же ATL или MFC — там макрос на макросе и макросом погоняет. Там, где в Delphi наш общий знакомый просто встроил message maps в язык, расширив синтаксис, MFC реализовал "мини-расширение" синтаксиса плюсов при помощи макросов.

И так устроены практически все известные мне плюсовые фреймворки. Как только появляется нужда в DSL — хреначатся макросы BEGIN_SOMETHING_MAP(), END_SOMETHNG_MAP(), DEFINE_SOMETHING_HANDLER() — и поехали, вперёд и с пестней.

Кэр>Ну собственно все остальное мне обсуждать особо неинтересно. Я не верю в какую-либо массовую аудиторию для Немерле, которая будет создать языки для решения прикладных задач. И я считаю, что даже если вдруг здесь попрет массовость, то сразу же попрут названные мной проблемы. И тут хоть вы хором, хоть по очереди можете меня уверять, что мол никаких проблем никогда с этим не будет — для меня ваши заверения вообще не аргумент. Надо посмотреть на практику. И нет я не буду тем, кто эту практику вдруг начнет реализовывать. Тренируйтесь вон на кошках на романтиках.
Да не переживай ты так. Вроде бы никто не заставляет тебя романтикой-то заниматься %)

S>Поэтому, на мой взгляд, польза сводится к трансляции изолированных функций типа IsValidEma
ВВ>>И самое забавное, что как раз одна из основных проблема джаваскрипта, которую в идеальном мире хотелось бы решить — это бедность доступных на нем библиотек.
S>Возможно. Лично я в джаваскрипте не особо силён. Мне казалось, что основная проблема там — отсутствие автокомплита и интеллисенса.

Ну, современные IDE уже научены понимать даже фреймворки яваскриптовые и всякие извращения типа расширения объектов методами фреймворков. Хотя еще есть, куда улучшаться, естественно

ВВ>>Не знаю, не уверен. По идее все, что нам может на Си помешать реализовать АСП.НЕТ MVC — будет мешать и в Си++.
S>Какая-то вывернутая логика. Мешать нам ничто не мешает. Вопрос в том, что нам помогает.
S>Если в языке нет понятия "типизированный указатель на функцию", то нам ничто уже не поможет его эмулировать — только рукопашный код, без какой-либо поддержки компилятором.

ВВ>>Но Си это все же язык, который создавался задолго до эпохи веб. А на любом более или менее современном языке, включая динамические скрипты, фреймворк соответствующий возможностям MVC реализуем. Даже наоборот — это на C# затруднительно сделать что-либо вроде РубиОнРаилс.
S>Возможно. Я весьма поверхностно знаком с рельсой.

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

Расширяем C# до Немерле и http://code.google.com/p/nemerleonrails/

S>Вот тут линк должен очень-очень сильно помочь.

.net-ный linq очень плохо помогает при условных запросах.
когда конечный запрос собирается из кусочков на основе ввода пользователя (например, по каким полям фильтровать и сортировать)

зы
еще у нескомпилированного linq на каждый запрос куда-то уходит ровно 50мс, соответственно больше 20 запросов в секунду не сделать.

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

S>>Вот тут линк должен очень-очень сильно помочь.

DG>.net-ный linq очень плохо помогает при условных запросах.
DG>когда конечный запрос собирается из кусочков на основе ввода пользователя (например, по каким полям фильтровать и сортировать)

Это сравнению с чем плохо? С whereString += " AND Filed=@Field"?

DG>зы
DG>еще у нескомпилированного linq на каждый запрос куда-то уходит ровно 50мс, соответственно больше 20 запросов в секунду не сделать.

Ну вот еще одна проблема, которую легко решает МП. Впрочем тулкит вроде сам кеширует компилированные запросы.

DG>>в текстовых терминах проще формулировать утверждения.
DG>>если рассматривать МП не в текстовых терминов — то там слишком много незнакомых терминов надо вводить.

МП большая область
если заходить со стороны ЯП: то это будет теория множеств, категорий, алгебры, логика первого/второго порядка, индукция, изоморфизм, грамматика, лексика, лямбда-исчисление и т.д.
если заходить со стороны исследования операций: то это будет детерминированные модели, линейное программирование, симплекс-метод, транспортные модели, сетевые модели и т.д.
можно зайти со стороны оптимального управления, теории игр и т.д.
что именно интересует?

Z>Это каких же? Что-то я не заметил, что ты скромен в количестве термиинов.
Z> Той же семантики навалил целую кучу и в тему и не в тему.

это лишь показать, что термин "семантика" — это вообще о другом.
vlad, wh и sinclair говорят о той или иной эквивалентности программ, но не о семантике.

Z>А от тебя я все еще жду реальные примеры применения МП. Ведь у тебя множество исследовательских проектов применяющих МП. Не обязательно код, у тебя же наверняка NDA Просто проблема, способ решения.

проблема:
в стандартной трехзвенке — для описания бизнес-логики приходится использовать три с половиной языка: c#, sql, js и xpath
решение:
введение единого языка для описания бизнес-логики — который транслируется во все эти три с половиной языка

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

решение:
код записывается как последовательный-синхронный, но автоматически преобразуется в cps

проблема:
удобная объектно-ориентированная запись бизнес-логики приводит к большому кол-ву запросов к базе

решение:
поддержка двухфазной модели выполнения бизнес-логики:
на первой фазе пробегом по дереву БЛ определяется какие данные она требует и склеивание в единый запрос, данные запрашиваются и складываются в кэш
на второй фазе — БЛ исполняется поверх кэша

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

Кэр>>Спорно, но допустим. Как отсюда возьмется аудитория для Немерле? Ты пытаешься сказать, что препроцессорными директивами в плюсах какая-то видимая часть аудитории пытается создать новый язык?
S>Конечно! Наивно этого не видеть.

Наивно это пытаться тут увидеть

S>Посмотри на тот же ATL или MFC — там макрос на макросе и макросом погоняет. Там, где в Delphi наш общий знакомый просто встроил message maps в язык, расширив синтаксис, MFC реализовал "мини-расширение" синтаксиса плюсов при помощи макросов.

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

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

S>И так устроены практически все известные мне плюсовые фреймворки. Как только появляется нужда в DSL — хреначатся макросы BEGIN_SOMETHING_MAP(), END_SOMETHNG_MAP(), DEFINE_SOMETHING_HANDLER() — и поехали, вперёд и с пестней.

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

S>Да не переживай ты так. Вроде бы никто не заставляет тебя романтикой-то заниматься %)

Хых. Ты и правда думаешь, что я переживаю?

DG>>.net-ный linq очень плохо помогает при условных запросах.
DG>>когда конечный запрос собирается из кусочков на основе ввода пользователя (например, по каким полям фильтровать и сортировать)

Z>Это сравнению с чем плохо? С whereString += " AND Filed=@Field"?

по сравнению с тем, что идея linq может предложить.

через linq — даже изменение порядка сортировки делается очень геморройно, т.к. для сортировки используется аж 4 метода

DG>>зы
DG>>еще у нескомпилированного linq на каждый запрос куда-то уходит ровно 50мс, соответственно больше 20 запросов в секунду не сделать.

Z>Ну вот еще одна проблема, которую легко решает МП. Впрочем тулкит вроде сам кеширует компилированные запросы.

может, что-то даже делает, но 50мс никуда не деваются. (четкие 50 мс связаны скорее всего с какими-то потерями на переключение потоков)


Z> Ну вот еще одна проблема, которую легко решает МП.

так здесь как раз удобны inline-"макросы", которые как раз возвращают несколько выражений

например, можно сделать так:

 world.Managers.MyOrderBy({Name:asc, Money: desc})

а склейку кортежа сделать доп функциями
при этому MyOrderBy — возвращает последовательность из OrderBy.ThenBy

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

Z>Но 2010 надо поддержать, как ни крути, пусть простейшую интеграцию, без сенса и прочего.

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

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

Кэр>Наивно это пытаться тут увидеть
Клиника.

Кэр>ATL и MFC никак не тянут на расширения языка народными массами.
И что же в них такого?
Я сам когда на С++ писал полобными трюками пользовался.

Кэр>Это фреймворки, которые решают единственную задачу — предоставить свой функционал.
А что есть фреймворки которые решают другую задачу

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

Кэр>Просто потому что задача расширения синтаксиса языка общего назначения — это очень и очень большая ответственность.
Ты не путай хардкод в компилятор который появляется у всех и навсегда.
И макрос который хочу использую не хочу не использую.
В немерле 2 гранулярность подключения синтаксиса будет доведена до предела.
Например можно будет делать так:

{
    using Nemerle.Xml.Literal;//Подключили синтаксис
    //разбираем xml литерал:
    <asd qwe="asdasda">
    </asd>
}//А вот тут синтаксис отключится.
//И следующий код уже не будет компилироваться.
    <asd qwe="asdasda">
    </asd>

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

Кэр>должны быть условия проекта, которые это позволяют и
Условия проекта очень простые: У разработчиков должны быть мозги.
Впрочем разработчики без мозгов всеравно ничего хорошего не сделают.

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

Кэр>В плюсах это обусловленно невыносимым размером необходимого boilerplate кода. В C# мы не наблюдаем этой картины, хотя язык решает почти все те же задачи.
Да правда чтоли?
Ты WPF видел?
Как dependency property объявить знаешь?

Кэр>Хых. Ты и правда думаешь, что я переживаю?
А чтож ты тогда в каждую тему лезешь?

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

DG>.net-ный linq очень плохо помогает при условных запросах.
DG>когда конечный запрос собирается из кусочков на основе ввода пользователя (например, по каким полям фильтровать и сортировать)
И в чем проблема?

DG>зы
DG>еще у нескомпилированного linq на каждый запрос куда-то уходит ровно 50мс, соответственно больше 20 запросов в секунду не сделать.
Ты про какую из реализаций?
http://www.ormbattle.net/index.php/scorecard.html
Там даже у самый тормоз на порядок быстрее чем ты говоришь.

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

WH>Условия проекта очень простые: У разработчиков должны быть мозги.

Тогда мейнстрим точно не светит