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

WH>А немерле нет. Парсер слабый. В нитре на которой будет немерле2 подобных ограничение изначально не будет.
Не в обиду, но я от тебя лет 5 минимум слышу, что вот, почти завтра, в немерле следующей версии все будет круто, и вообще порвет в катяхи c#. И метапрограммирование станет полезным и доступным каждому.
Вот только это «завтра» никак не наступает, по большому за 5 лет ничего не изменилось и вряд ли изменится. Слишком сильно он отстал. Не как язык, а как идея.

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

WH>>А немерле нет. Парсер слабый. В нитре на которой будет немерле2 подобных ограничение изначально не будет.
G>Не в обиду, но я от тебя лет 5 минимум слышу, что вот, почти завтра, в немерле следующей версии все будет круто, и вообще порвет в катяхи c#. И метапрограммирование станет полезным и доступным каждому.
Он и сейчас рвёт C#.
И сейчас метапрограммирование проще чем где бы то ни было.
Просто будет ещё проще.

G>Вот только это «завтра» никак не наступает, по большому за 5 лет ничего не изменилось и вряд ли изменится.
То, что ты не видишь, не значит, что ничего не изменилось.

G>Слишком сильно он отстал. Не как язык, а как идея.
От кого отстал? Имя сестра. Имя!

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

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

WH>>>А немерле нет. Парсер слабый. В нитре на которой будет немерле2 подобных ограничение изначально не будет.
G>>Не в обиду, но я от тебя лет 5 минимум слышу, что вот, почти завтра, в немерле следующей версии все будет круто, и вообще порвет в катяхи c#. И метапрограммирование станет полезным и доступным каждому.
WH>Он и сейчас рвёт C#.
Разве в nemerle есть async? Или есть razor? Даже linq нормального нет.

WH>И сейчас метапрограммирование проще чем где бы то ни было.
WH>Просто будет ещё проще.
Это лишь слова. Покажи в сравнении с roslyn. Немерле2 покачто фантастика, а roslyn уже реален. Просто возьми примеры от roslyn и сравни. И не банальщину типа INotifyPropertyChanged или генерацию классов по внешним метаданным, потому что эта проблема в C# уже решена.

G>>Вот только это «завтра» никак не наступает, по большому за 5 лет ничего не изменилось и вряд ли изменится.
WH>То, что ты не видишь, не значит, что ничего не изменилось.
Для меня ничего не изменилось, при этом я активно мониторю ситуацию. А 99% остальных вообще насрать на немерле.

G>>Слишком сильно он отстал. Не как язык, а как идея.
WH>От кого отстал? Имя сестра. Имя!
От текущей реальности отстал. Уже тонны кода написаны на java, c# и даже f# с его typeprovider. Тысячи практических задач решены. Не сможет метапрограммирование в немерле дать что-нибудь полезное.

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

G>Разве в nemerle есть async?
Есть. И не один. Причём появились ещё до того как оно появилось в C#.

G>Или есть razor?
Есть круче.

G>Даже linq нормального нет.
Ну да... то что нужно написать linq<# #> это конечно большая беда.

G>Это лишь слова. Покажи в сравнении с roslyn. Немерле2 покачто фантастика, а roslyn уже реален.
roslyn тоже ещё фантастика.

G>Просто возьми примеры от roslyn и сравни. И не банальщину типа INotifyPropertyChanged или генерацию классов по внешним метаданным, потому что эта проблема в C# уже решена.
И что конкретно ты хочешь увидеть?

G>Для меня ничего не изменилось, при этом я активно мониторю ситуацию. А 99% остальных вообще насрать на немерле.
Не верю. Иначе бы знал и про async и про Nemerle.Web.

G>От текущей реальности отстал. Уже тонны кода написаны на java, c# и даже f# с его typeprovider. Тысячи практических задач решены. Не сможет метапрограммирование в немерле дать что-нибудь полезное.
Тем кто его реально использует, даёт. А вы всё не даёт да не даёт.

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

Имхо зря ты напираешь на преобразование синхронщины в асинхронщину. Это не одна, а две связанных задачи, одна из которых уже решена — в Nemerle даже беты были средства преобразования кода позволяющие построить из любого куска цепочку вложенных друг в друга продолжений. Дальше всё совсем легко, глядя одним глазом в существующие реализацию async/await вызывать нужную тебе функцию и выполнять её продолжение по завершении. Т.е. async/await из C# только без необходимости писать эти ключевые слова. Для функций которые не зависят друг от друга по данным, ты сам, уверен, сделаешь такой макрос глядя в доки и то что уже наработано. И он закроет примерно 80% сценариев. Но:

останется, как писал Эрик Липперт, ещё 80%: сделать так чтобы всё это работало без сильных глюков и давало какой-то профит. Ты сам называешь вторую часть задачи вот здесь:

I>Если имеем дело с чистым ДСЛ, то нет никаких проблем. А вот что делать с ЯОН ?

Вот тут есть проблема. При переводе _любой_ функции (как поставлена задача) в асинхронную — макросу поглупее придётся оборачивать в локи буквально каждый объект и вызов метода (и то не факт что будет работать), просто потому что преобразование функции в асинхронную как-бы подразумевает что она может быть вызвана несколько раз до своего завершения, может использовать и изменять состояние каких-то объектов, и это надо как-то согласованно менять. Макросу поумнее придётся строить граф вызовов и какими-то эвристиками решать где тут можно отделаться Interlocked, где заменять lock(this) на эквивалент работающий на пуле, а где рыбу заворачивали.

Между прочим в Nemerle эту вторую задачу решать в разы проще — именно из-за неизменяемости переменных и функционального стиля случаев когда макрос споткнётся о какую-то нетривиальную замену кода, или мутабельную переменную, минимизированы. Вплоть до того что можно просто лапки подвешивать и говорить что преобразование невозможно, как часто делает C# — ограничений на методы с преобразованиями кода целая куча — yield return и try/catch; lock и async; обломы с ref/out, и т.п.

Из-за того что само преобразование возможно, и его реализация лишь вопрос затраченных усилий, — прав WolfHound. Из-за того что конкретно это преобразование не только не реализовано, но ещё и сама реализация может легко выкатиться за человеко-год, без гарантий что всё будет работать на 100% кода, вроде как и ты тоже прав. И никогда вы не договоритесь

G>Разве в nemerle есть async? Или есть razor? Даже linq нормального нет.

Примеры разных async-ов появились наверное в 2010-м. И их можно свободно менять под задачу, в отличии от прибитых гвоздями реализаций в C#.

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

S>Паттерн или нет?

S>

S>#define container_of(ptr, type, member) ({                      \
S>          const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
S>          (type *)( (char *)__mptr - offsetof(type,member) );})
S>

Сишный говнокод.

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

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

G>>Разве в nemerle есть async?
WH>Есть. И не один. Причём появились ещё до того как оно появилось в C#.
И всем крайне далеко до C#.
Необходимо чтобы умело работать с тасками.
Необходимо чтобы синтаксический оверхед был на уровне не выше C#, то есть два ключевых слова.
Увы такого в nemerle нет и не будет.

G>>Или есть razor?
WH>Есть круче.
Не круче. Все что есть это поделка на уровне WebSharper. Все такие поделки имеют два критических недостатка: а) сложно готовый html (реальный, а не 3 строки из примеров) переделать в такой шаблон б) композиция шаблонов делается через код жопу.


G>>Даже linq нормального нет.
WH>Ну да... то что нужно написать linq<# #> это конечно большая беда.
Огромная. Только она одна делает nemerle неюзабельным для практических задач.

G>>Это лишь слова. Покажи в сравнении с roslyn. Немерле2 покачто фантастика, а roslyn уже реален.
WH>roslyn тоже ещё фантастика.
Да ладно? Ты не обратил внимание что в ASP.NET MVC 5 используется roslyn для компиляции razor?
Так что реальность, причем более чем Nemerle.

G>>Просто возьми примеры от roslyn и сравни. И не банальщину типа INotifyPropertyChanged или генерацию классов по внешним метаданным, потому что эта проблема в C# уже решена.
WH>И что конкретно ты хочешь увидеть?
Что-нибудь значительно улучшающее процесс разработки без заметного геморроя для программистов.
Вот Синклер приводил пример про иерархию метаклассов в Delphi, повторить такое на Nemerle.
Или еще одна фишка, которая может упростить жизнь разработчикам библиотек — нечто похожее на variadic templates в C++, чтобы удобно и красиво делать варируемое число параметров функции с обработкой на этапе компиляии.

G>>Для меня ничего не изменилось, при этом я активно мониторю ситуацию. А 99% остальных вообще насрать на немерле.
WH>Не верю. Иначе бы знал и про async и про Nemerle.Web.
Я знаю, и знаю что это отстой. Для реального применения в разы хуже того что есть в C#.

G>>От текущей реальности отстал. Уже тонны кода написаны на java, c# и даже f# с его typeprovider. Тысячи практических задач решены. Не сможет метапрограммирование в немерле дать что-нибудь полезное.
WH>Тем кто его реально использует, даёт. А вы всё не даёт да не даёт.
Ну да, всем четырем человекам, которые реально используют может что-нибудь и дает. Прости, но даже F# побольше дает.

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

G>>Разве в nemerle есть async? Или есть razor? Даже linq нормального нет.

_>Примеры разных async-ов появились наверное в 2010-м. И их можно свободно менять под задачу, в отличии от прибитых гвоздями реализаций в C#.

Да-да, слизанные с F# 1-в-1. Только async в F# несмотря на мощность используется довольно слабым спросом, а async в C# используют почти все.

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

G>И всем крайне далеко до C#.
G>Необходимо чтобы умело работать с тасками.
G>Необходимо чтобы синтаксический оверхед был на уровне не выше C#, то есть два ключевых слова.
G>Увы такого в nemerle нет и не будет.
Ну, зачем же врать то?
https://github.com/rsdn/nemerle/blob/master/snippets/Nemerle.Async/WindowsFormsTest/MainForm.n

G>>>Или есть razor?
WH>>Есть круче.
G>Не круче. Все что есть это поделка на уровне WebSharper.
Они не имеют между собой ничего общего.
WebSharper серверный шаблонизатор.
NemerleWeb клиентский GUI.

G>Все такие поделки имеют два критических недостатка: а) сложно готовый html (реальный, а не 3 строки из примеров) переделать в такой шаблон
Это сложно? Лично я вижу разор с точность до синтаксиса.

  [Html]
  View() : string
  {
    <#
      <div>
        Title
        <input value="$(TaskToAdd.Title)" />
        Priority
        <select value="$(TaskToAdd.Priority)">
          <option value="0">low</option>
          <option value="1">kinda important</option>
          <option value="2">really hungry!</option>
        </select>
        <button click="$AddTask">Add task</button>
        <ul>
          <li $foreach(t in Tasks.OrderByDescending(t => t.Priority))>
            $(t.Title) ($(t.Priority))
            <input type="checkbox" checked="$(t.Status)" />
          </li>
        </ul>
      </div>
    #>
  }

G>б) композиция шаблонов делается через код жопу.
Что?

G>Что-нибудь значительно улучшающее процесс разработки без заметного геморроя для программистов.
G>Вот Синклер приводил пример про иерархию метаклассов в Delphi, повторить такое на Nemerle.
Это не сложно. Но зачем?

G>Или еще одна фишка, которая может упростить жизнь разработчикам библиотек — нечто похожее на variadic templates в C++, чтобы удобно и красиво делать варируемое число параметров функции с обработкой на этапе компиляии.
В реальности это костыли для недометапрограммирования. В немерле нормальное есть.

G>Я знаю, и знаю что это отстой. Для реального применения в разы хуже того что есть в C#.
Не знаешь.

G>Ну да, всем четырем человекам, которые реально используют может что-нибудь и дает. Прости, но даже F# побольше дает.

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

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

G>>И всем крайне далеко до C#.
G>>Необходимо чтобы умело работать с тасками.
G>>Необходимо чтобы синтаксический оверхед был на уровне не выше C#, то есть два ключевых слова.
G>>Увы такого в nemerle нет и не будет.
WH>Ну, зачем же врать то?
WH>https://github.com/rsdn/nemerle/blob/master/snippets/Nemerle.Async/WindowsFormsTest/MainForm.n
Сорри, это как раз и пропустил. А зачем еще способы нужны?

G>>>>Или есть razor?
WH>>>Есть круче.
G>>Не круче. Все что есть это поделка на уровне WebSharper.
WH>Они не имеют между собой ничего общего.
WH>WebSharper серверный шаблонизатор.
WH>NemerleWeb клиентский GUI.
Эта фраза ни о чем.

G>>Все такие поделки имеют два критических недостатка: а) сложно готовый html (реальный, а не 3 строки из примеров) переделать в такой шаблон
WH>Это сложно? Лично я вижу разор с точность до синтаксиса.
WH>

WH>  [Html]
WH>  View() : string
WH>  {
WH>    <#
WH>      <div>
WH>        Title
WH>        <input value="$(TaskToAdd.Title)" />
WH>        Priority
WH>        <select value="$(TaskToAdd.Priority)">
WH>          <option value="0">low</option>
WH>          <option value="1">kinda important</option>
WH>          <option value="2">really hungry!</option>
WH>        </select>
WH>        <button click="$AddTask">Add task</button>
WH>        <ul>
WH>          <li $foreach(t in Tasks.OrderByDescending(t => t.Priority))>
WH>            $(t.Title) ($(t.Priority))
WH>            <input type="checkbox" checked="$(t.Status)" />
WH>          </li>
WH>        </ul>
WH>      </div>
WH>    #>
WH>  }
WH>

0) Выражения внутри тегов это жесть
1) Куда это вписывать? В код контроллера?
2) Как делается композиция?
3) Как делаются хелперы?



G>>б) композиция шаблонов делается через код жопу.
WH>Что?
То что прочитал

G>>Что-нибудь значительно улучшающее процесс разработки без заметного геморроя для программистов.
G>>Вот Синклер приводил пример про иерархию метаклассов в Delphi, повторить такое на Nemerle.
WH>Это не сложно. Но зачем?
Не реже раза в месяц появляется вопрос на эту тему в форуме по .NET.

G>>Или еще одна фишка, которая может упростить жизнь разработчикам библиотек — нечто похожее на variadic templates в C++, чтобы удобно и красиво делать варируемое число параметров функции с обработкой на этапе компиляии.
WH>В реальности это костыли для недометапрограммирования. В немерле нормальное есть.
Покажи пример, а то снова та же песня: вроде все есть, только по факту никто не использует.

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

WH>>WebSharper серверный шаблонизатор.
WH>>NemerleWeb клиентский GUI.
G>Эта фраза ни о чем.
Думаю, прежде чем вообще продолжать разговор тебе нужно понять, о чём эта фраза.
http://www.nemerleweb.com/tutorial

G>0) Выражения внутри тегов это жесть
И чего такого?

G>1) Куда это вписывать? В код контроллера?
Думаю, тебе всё же стоит разобраться с тем, о чём ты вообще говоришь.

G>2) Как делается композиция?
http://www.nemerleweb.com/tutorial#Templates

G>3) Как делаются хелперы?
Что?

G>Не реже раза в месяц появляется вопрос на эту тему в форуме по .NET.
Не знаю как сейчас, но раньше там и про деструктры вопросы появлялись.

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

WH>Паттерн это копипаста неустранимая средствами выбранного языка.
WH>В похожих языках (C# и Java) паттерны похожи. В сильно разных (C# и haskell) сильно разные.
WH>В языках с качественным метапрограммированием найти паттерны не просто. Ибо трудно придумать копипасту которую не устранить метапрограммированием.

Имхо, не все паттерны удовлетворяют такому условию.
Facade, Mediator и Chain-of-responsibility — не ясно, что там можно устранить.

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

S>А вот тут, на мой взгляд, лучше вообще не пытаться использовать паттерны как аргумент для выбора. Для отдельных решений ошибочно выбранный паттерн ещё можно исправить, а вот основу архитектуры лучше закладывать исходя из практических соображений. Смотреть на характер нагрузки, уровень команды, опыт похожих решений, используемый язык/фреймворк и т.д. и т.п. Абстрактных универсальных ответов тут нет и не может быть

Очень похожие соображения совсем недавно Тёма добавил в Ководство: Правило по составлению правил — у него про дизайн, но фактически это универсальное правило. Ну ещё вспоминается из Фаулера

Автор: Дм.Григорьев
Дата: 02.07.07

.

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

S>В C# не нужнен паттерн "Publisher/Subscriber", потому что есть языковые понятия event и delegate.

Всё-таки мне думается, ты смешиваешь понятие "паттерн" (который суть чистая идея, абстракция) и "реализация паттерна". В твоём примере event/delegate — реализация паттерна publisher/subscriber на конкретном языке. Принципиально нет никакой разницы, реализован паттерн средствами языка, DSL или библиотеки; разница только в удобстве использования.

Здравствуйте, dimgel, Вы писали:
D>Всё-таки мне думается, ты смешиваешь понятие "паттерн" (который суть чистая идея, абстракция) и "реализация паттерна". В твоём примере event/delegate — реализация паттерна publisher/subscriber на конкретном языке. Принципиально нет никакой разницы, реализован паттерн средствами языка, DSL или библиотеки; разница только в удобстве использования.

Конечно же ты прав. Но в самой чистой идее есть какие-то конкретные черты, благодаря которым мы можем понять, что вот этот код — это фабрика, а тот код — не фабрика.
Если таки открыть любой источник, рассуждающий в терминах паттернов, то окажется, что там приведено вполне конкретное решение.
Вот, например, http://citforum.ru/SE/project/pattern/p_2.shtml#3.3.1:

Решение: Создать абстрактный класс, в котором объявлен интерфейс для создания конкретных классов.

То есть — сразу имеем

public abstract class ControlFactory
{
  public abstract Control CreateControl(Control parent);
}

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

public interface IControlFactory
{
  Control CreateControl(Conrol parent);
}

и

public delegate Control ControlFactory(Control parent);

и даже

using ControlFactory = Action<Сontrol, Control>;

Использование терминов типа "абстрактный класс" сразу же выдаёт родной язык авторов паттерна.

Конечно же, когда мы говорим о языковом понятии, мы фиксируем какую-то более-менее конкретную реализацию абстрактного понятия.
В зависимости от предпочтений авторов языка, можно либо вообще зафиксировать ровно одну реализацию (например, параллельная иерархия метаклассов в Delphi, которые, в сочетании с виртуальными конструкторами могут выступать в качестве абстрактных фабрик), либо дать на выбор несколько реализаций (например, virtual и dynamic methods в том же Delphi используют разную структуру VMT), либо вообще отделить реализацию от декларации (например, query expressions в Linq).

Тем не менее, нужно понимать, что при грамотной реализации, языковое понятие на 99.99% устраняет нужду в самом понятии "паттерна".
Типичным примером является паттерн "procedure call". Несмотря на то, что это — всего лишь "чистая идея", "абстракция", подавляющее большинство программистов не только не отдают себе отчёт в существовании такого паттерна, но зачастую не верят в него даже после наглядной демонстрации.

За десятилетия существования "встроенных реализаций" этого паттерна даже различия в его реализации выкристаллизовались в отдельное понятие "calling convention".

Поэтому в современном мире можно спокойно игнорировать наличие абстрактных идей в практически любой коммуникации между разработчиками, и уж тем более — в рамках одного проекта.
Никто не говорит "используй паттерн Реентерабельный Вызов Процедуры в сочетании с паттерном Таблица Виртуализуемых Методов". Говорят "вызови метод IHttpHandler.ProcessRequest()".

Точно так же в Delphi проектах никто не говорит "используй паттерн Абстрактная Фабрика для того, чтобы позволить прикладному программисту заменять тип создаваемых объектов". Говорят "добавь свойство ChildItemType классового типа, и вызывай виртуальный конструктор на нём".

Здравствуйте, artelk, Вы писали:
A>Имхо, не все паттерны удовлетворяют такому условию.
A>Facade, Mediator и Chain-of-responsibility — не ясно, что там можно устранить.
Ну, вот например реализация Фасада для COM сопряжена с некоторыми проблемами — это же частный случай Aggregation, с вытекающими обязанностями по отслеживанию reference counts.
B итоге фасад превращается в тонны boilerplate кода, который уныл, однообразен, и вся польза его — в возможности допустить ошибку.
А вот в Delphi есть встроенная в язык поддержка агрегации, называется, ЕМНИП, interface delegation.
То есть в нём изготовление фасада делается на раз-два:

property MyInterface: IMyInterface read FMyInterface implements IMyInterface
property MyInterface2: IMyInterface2 read FMyInterface2 implements IMyInterface2

И нам не нужно переписывать все 50 методов каждого интерфейса в наш фасад.

Если покопаться, то почти для всех паттернов можно найти устранимый boilerplate.

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

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

_>Имхо зря ты напираешь на преобразование синхронщины в асинхронщину.
...
>И он закроет примерно 80% сценариев.



I>>Если имеем дело с чистым ДСЛ, то нет никаких проблем. А вот что делать с ЯОН ?

_>Вот тут есть проблема. При переводе _любой_ функции (как поставлена задача) в асинхронную — макросу поглупее придётся оборачивать в локи

Локи и прочее, что ты указал, это только один из вариантов. В кратце — макросам придется думать, как обслуживать состояние, потому что на ровном месте образуются разделямые ресурсы и соответствующие конфликты.

Теоретически, решение есть — надо взять да и реализовать на макросах сущности навроде монад типа Future, Stream, State, обеспечить внятную ленивость, хитрые лифтинги и тд.
Я боюсь даже оценить сложность полученного решения.

_>Между прочим в Nemerle эту вторую задачу решать в разы проще — именно из-за

Я боюсь, что это "проще" неизмеримо, ибо должной квалификацией в макрах обладают единицы


_>Из-за того что само преобразование возможно, и его реализация лишь вопрос затраченных усилий, — прав WolfHound.

"возможно" наглядно демонстрируется разными компиляторами. Это как бы очевидно и совсем не понятно, почему WH повторяет это из года в год. Я говорю именно о сложности решения.