I>А что конкретно из макросов пригодилось, ну, кроме логирования ?

Там две итерации было. В первой (2007-2008г) мы только учились, поэтому там было буквально пара макросов, остальное врукопашную, C# style and flow, только с упором на паттерн-матчинг и ФП.

Вторая итерация была сильно позже (2009г) и умели мы гораздо больше, но понимали всё ещё столько же . Ну правильно, макросов же ещё не писали толком. А главное, пока было оплачиваемое время между первой и второй итерациями, — лепили фреймворк. И не то чтобы он оказался совсем не нужен, просто наше представление о программирование было всё ещё сильно искажено призмой C# и даже C++.

Вот пример — подметили что многие (да наверное все) объекты, подерживающие IDisposable, делают Dispose вложенным объектам, что, в принципе, логично. Для этого придумали аттрибут AutoDispose, который должен был использоваться примерно так:

[AutoDispose]
class A : IDisposable
{
  [AutoDispose]
  private b : B;

  [AutoDispose]
  private c : C;
}

Ну и типа генерируется православный метод метод Dispose, который там Dispose(disposing : bool), GC.SuppressFinalize, и вложенным объектам тоже Dispose если надо, в общем всё хорошо. Макрос был весело написан, и через неделю использования оказалось что есть один нюанс — эти [AutoDispose] не нужны как тот скрипач. В итоге всё выродилось до полностью автоматической реализации IDisposable, без всяких аттрибутов вообще. Ориентиром было наличие самого интерфейса IDisposable. Т.е. если класс заявлял что он IDisposable, но не давал самописной реализации своего Dispose, то создавалась реализация "по-умолчанию" для всех приватных и протектед полей. Оказалось удобно и надёжно, писанины меньше, меньше места для ошибок.

Второй пример, мы лепили хитрый макрос, для особых полей и свойств, чтобы их случайно нельзя было изменить откуда-то, откуда нельзя. При этом существовала группировка по строковым ключам. Идея была такой:

class ACollection : IList
{
  [ModifcationGroup("IList")]
  public Count : int { get; protected set; }

  [ModifcationGroup("IList")]
  public Add(value : object) : int
  {
  }
}

Ну и типа только методам из одной группы можно менять поля/свойства из этой группы. Красиво, но быстро надоело, и как только столкнулись с этим в реальной жизни, заменили на простецкий аттрибут:

class ACollection : IList
{
  [ChangedBy(Add, Remove, Clear)]//это имена методов, которым разрешено менять Count
  public Count : int { get; set; }
}

Теперь если кто-то попытается изменить Count в каком-то другом методе — получает ошибку времени компиляции. Если какого-то метода нет — тоже ошибка компиляции. Для чтения Count даёт лок-фри кэшированное значение. Главное декларативно и сразу видно кто может лазить в Count. Жалко только goto definition для этой штуки не работал — с Location мы как-то не разобрались в тот раз. Посмотрим насколько проще с этим будет в N2

Или вот слепили мы хитрые методы для синхронизации, там можно было в нашей реализации lock перечислять объекты через ",". Кроме того была секция то-ли late, то-ли reserve, в которой можно было перечислить что ты собираешься лочить потом, после того как залочишь свой объект. Это было придумано для того чтобы обеспечить гарантированно без-деадлочную блокировку. Обеспечили, а оно оказалось втопку. Зато его место заняли несколько макросов вида readlock(object), writelock(object). Вот только был маленький секрет — эти макросы лочили не сам объект, а его SyncRoot, причём если у объекта не было своего SyncRoot, но ему в конструктор передавался другой объект(родитель), со своим SyncRoot, то лочился родительский SyncRoot, ну и так в цикле, пока у кого-нибудь не найдётся SyncRoot. Самое главное что если SyncRoot был object — то макросы превращались в обычнй Monitor.Enter. А вот если SyncRoot был ReaderWriterLock — то тогда в вызовы его методов. А если SyncRoot был ReaderWriteLockSlim, то ещё проверялось на то, держим мы уже лок или нет, потому как ReaderWriterLockSlim не поддерживает реентерабельность. Да, и во избежание ошибок мы библиотечный lock подменили на наш write_lock. Магии много, но пока она незаметная и её не надо держать в голове — кода рукопашного мало, а значит пользоваться удобно и накосячить сложно.

Кроме того много работы выполняли макросы и стиль программирования, за которые в C# проекте я бы руки отрывал. Например нужно было устанавливать связь с разными старыми системами, написанными чёрт знает на чём. Для каждой такой системы был заведён свой проект, с одинаковой иерархией namespace'ов. И в них была строгая иерархия наименования типа Root.Api.XyzTasks, Root.Api.XyzSerializer, Root.Comm.XyzListener и т.п. Так вот если в имени класса было Xyz, то автоматом генерировались пачками приватные члены, характерные для этой системы. Если при этом ещё и namespace Comm, то создавалась прокся с полностью асинхронными вызовами тех public методов что имелись в классе. Ну и так далее.

Или вот ещё ацкий трэш — у нас некоторые исключения имели помимо важности ещё свойство Color, которым (ааа111!!!) их надо было подсвечивать в GUI. Выставлялось это свойство автоматом, исходя из того в каком классе, в процессе работы над какой задачей, случился throw. Почему такое нарушение принципов вообще оказалось возможно — а потому что оно не выставлялось вручную вообще нигде. Т.е. GUI код просто использовал это свойство, и ему по-барабану как оно возникло, а программист который исключение кидал — даже не знал про какое-то там свойство, и его не выставлял. Соотвественно если бы мы решили эту хрень заменить, или вообще убрать — надо было бы менять только одно место, а значит принципы правильного разделения BL и GUI можно слать в конкретно этом случае лесом.

Очень полезными оказались прекомпилируемые регекспы, которые были быстрые как компилируемые, и описанные прямо в коде. Кроме того у Nemerle есть свой match/биндинг по регекспам (называется кажется rx match или regex match), и мы по образу и подобию слепили себе такой же, но почему и чем он был лучше — уже не помню.

Множественное наследование оказалось не нужно вовсе. traits на интерфейсах оказалось что использовались только для сериализации, больше впихнуть было некуда, а сериализация была на лямбдах удобнее. Так и стали traits зомбями nUnit'ными.

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

И ещё — оказались очень нужны и важны макросы которые не добавляют функционал, а наоборот ограничивают использование чего-то откуда не планировалось, причём во время компиляции. Например нельзя лезть в объекты неймспейса GUI из объектов неймспейса Threading или Comm. Или нельзя приводить какой-то интерфейс больше ни к какому другому интерфейсу (полагаясь на тайное знание о том что там за интерфейсом какой-то конкретный объект). Это позволяет очень сильно снизить число ошибок причём без единого теста или захода в отладку. Таких штук мы вообще не задумывали в фреймворке, а потом использовали повсеместно.

А теперь ДЗЕН вынесенный из этого проекта:
Ближе к концу мы уже не стремились лепить библиотечные навороты и расширять фреймворк, а скорее старались заменять макросами рукопашный код насовсем но локально. Т.е. гораздо проще разработать какую-то феньку нужную в 5 местах и без параметров, и какую-то очень похожую феньку (даже внешне точно такую-же) для 5 других мест, чем лепить универсальную, конфигурируемую через кучу параметров мега-фень, способную покрыть все эти 10 мест и ещё 20 гипотетических похожих.

Ну и экономический момент. Ожидая проблем с отладкой макросов и самого проекта в котором будет много макро-магии, я сознательно завысил оценку времени на отладку раза в 3. Причём первый раз завысил, руководствуясь тем что язык новый, и тогда (2007-й год), интеграция ещё работала очень слабо, и некоторые штуки было проще написать в Far+Colorer чем в студии. А второй раз — завысил исходя из того что всю эту макро-магию потом отладчиком разбирать будет сложно. Оба раза зря.

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

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

WH>>>Ты лучше ссылку дай.
WH>>>А то пара человек с умным видом говорят, что это круто.
WH>>>Но ссылок на работы не дают.
_C_>>это Аноним не дает. я бы дал.
WH>Ты говоришь, что метасвязки это круто.
WH>Значит, ты про них читал.
WH>Значит, у тебя должны быть ссылки.
WH>Где они?

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

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

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

VE>>Давай поподробнее. Ты утверждаешь, что любая фича общего назначения не нужна?
WH>Я утверждаю, что для решения задачи нужны фичи позволяющие решать задачу в терминах задачи.
WH>При этом фичи общего назначения чуть менее чем всегда не имеют ничего общего с терминами задачи.
WH>Максимум на что они годятся это кривая и тормозная эмуляция фичей заточенных на задачу. А как правило и с этим справится не могут.
WH>Чем ты в своём примере с туплом и занимался. Причем что характерно ты опять делал фичу общего назначения.

У вас както получается программирование ради программирования,
а не программирование ради того, чтобы компьютер научить эффективно решать эту задачу.
Эффективно, это означает описать задачу наиболее близко к терминам архитектуры ЭВМ.
Вам стоило бы взглянуть на популярность Objective C в Айфонах и качество ПО там, взглянуть на WinCRT, взглянуть на все то что было написано на Си.
Это все довольно примитивное программирование, но чертовски эффективное.
Всякий раз когда тяните пальчиком иконку, заставку, крутите видео на мобильном, замечаете полупрозрачный эффект — вспоминайте Си, Обджектив Си, Си++
а не новомодные фреймворки и концепции.

Для всех красивых теорий, вспоминается печальный тезис:
"Есть много хороших программистов на Джава, но мало хороших программ на Джава"(с)
ИМХО если Немерле и обретет популярность, то ситуация будет еще печальней чем с этой всей новомодной функциональщиной,
код программы хоть в витрину ставь учить КАК писать потомков, а пользоватся программой — сорви и выкинь

VE>А есть какой-то критерий, как понять, понял я макросы или нет? Ну кроме очевидного "в восторге от них — значит понял".

Каждый раз когда применяется какой-то макрос, язык становится немного более DSL.

Наверное WolfHound хочет сказать что в случае достаточно годного DSL никакого технического кода, который к предметной области отношения не имеет, должно вовсе не остаться. Даже using namespace наверное не надо. Макросы сами подключат что нужно. Возможно и классы не нужны, если предметная область никаким боком не пересекается с ООП. Т.е. программа делится на две части — реализации DSL, и решение задачи на этом DSL. Всё то к чему мы привыкли, типа там паттернов, описания иерархий, и т.п., даже само понятие "именованная переменная" — может быть спрятано за DSL, если это удобно. Вот например если стоит задача выборки данных — LINQ годный DSL для основных случаев. В типичном запросе даже не упоминается то что там внутри какие-то IEnumerable или IQueryable, не указаны типы, в общем чистая выборка данных. Макрос ?? — подходящий DSL для типичного случая проверки на null и последующего присваивания, макрос .? — соотвественно для типичного случая проверки на null и последующего доступа.

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

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

ЗЫ: Телепате моде OFF

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

WH> Н2 может круче.
WH>На Н2 можно задать предметно ориентированную систему типов.
WH>И ловить ошибки предметной области без тонны кода построенного на побочных эффектах.

Вы своими конструкторами забыли простую вещь, что программист это человек который делает работу
программы эффективной, читаем в меньшее количество шагов достигается результат.
А это означает что языки программирования всегда такие какая архитектура ЭВМ по сути будут,
там нет места для вывода типов. И всякие шаражки типа Пролога, которые игнорируют сей факт,
пытаются ввести свои предметные ДСЛи, ожидает крупный феил.

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

Ты знаешь... это всё может быть важные, а может быть не важные проблемы.
Есть такой чуви, Алексей Пахунов — Not a kernel guy. Недавно дал интервью. Так вот мне очень понравился вопрос и ответ.

Каких возможностей вам не хватает в современных языках программирования?

Если в двух словах, то не хватает удобных средств борьбы со сложностью кода и возможности аналитически доказать корректность кода. К первым я бы отнес инструменты, помогающие находить сходные куски кода; диагностику, показывающую, как именно выполнялся код, как он может выполниться в похожих/граничных условиях; инструменты для статического и динамического анализа кода; возможность контролировать разрешённые конструкции языка; возможность расширять язык напрямую, вместо костылей типа перегрузки операторов и шаблонов в C++ и т.д.

К второй группе я бы отнес возможность задать (и гарантировать) условия, в которых должен выполнятся кусок кода (входные данные, определенное количество доступной памяти, немодифицируемость кода и данных, другие потоки не касаются той же памяти и т.п.) и возможность формально доказать корректность куска кода в данных условиях. Ну и на сладкое – возможность “сшить” такие формально доказанные куски кода в одну программу.

Жирным выделил. Почему мне это понравилось — потому, что, человек, насколько я понимаю весьма далёк от C#, .NET и Nemerle, далёк не сколько по способностям — а сколько по опыту работы — но почему же то потребности те же?
И насколько я вижу — N — практически единственный язык позволяющий это. То что позволяет N — иногда можно достичь и другими средствами, вот недавние скринкасты с NDC доказывают это — но так элегантно — едвали кто способен. И я вот в N реально удручен синтакслм дженерик параметров, — всё таки угловые скобки — почти стандарт, а с другой стороны, а что в C++? — ставить пробел перед закрывающей скобкой — обязаловка ныне — смешно же! Проблемы парсера?!?!? Ну да — а народ то хавает.
Да, текущий N — не идеален. Ну так он только начал развиваться по настоящему, с подключением команды RSDN и людей около ней. В общем — чем больше я знакомлюсь с N — тем больше я в восторге и тем более готов прощать недостатки, ведь преимуществ гораздо больше — а недостатки по большей мере, отностятся лишь к привычкам. Если уже IT пропагандирует N — видимо стоит серьёзно задуматься. Серьёзно.
А от "C# на стероидах" я вообще в восторге — это ведь решение кучи проблем, с минимальным ломанием команды разрабов. Сейчас мне приходится городить в рантайме (извините, но в T4 это не менее легче, — IL сгенерить не сложнее) реализацию WCF клиента, который бы соответствовал моим требованиям, стандратный, и тот шо на кодеплексе — всё не то, по факту — я то же мог бы сделать на N и макросах просто таки в разы проще... да, я сейчас не тороплюсь всё подряд переписывать на N.
Год назад я просто смотрел на N — а сейчас — смотрю с очень большим интересом, и уже жду смотрю где его будет удачнее приткнуть в уже действующий проект. И самое главное — я уже давно вижу, что код на N с его def — это то чего мне нехватает в C#, меня реально парит, что нельзя объявить "алиас", — в методе из трёх строк — это не проблема, в методе из 50 — не проблема пока его не трогают, в коде который генерит C# — это проблема отродясь — слоты задействует без необходимости.
Да и "любые конструкции — выражение", мне лично давно не хватает.

В CefGlue юзаю C# — потому, что а) unsafe код. Перед Xilium.CefGlue/3 — думал о N — но всётаки плотно юзаю unsafe (хотя он почти весь генерённый), — тем не менее, даст бог и N подключу — вроде бы точки где его можно было бы применить — просматриваемы. Да, кстати, вопрос о том, что open-source и народ тянется к C# — ерунда. Народ тянется к бинарникам и нифига не хочет фиксить — так что язык реально пофигу. Те кто хочет что-либо пофиксить — не поленяться установить петон, N и не поленяться вообще сами сбилдить CEF, что гораздо затратнее по времени и ресурсам...

Вот вам и недостатки.

PS: На NDC IT — реально клёва рассказал — имхо, в какой-то степени даже лучше Филиппа. Хотя оба молодцы. Филиппу бы посоветовал снести только то говно, которое НЕ билдит проекты, а должно.

Такие локальные функции как тебе надо, если довести до предельного обобщения — так это dynamic в C# и его последующая типизация/специализация. Насколько я помню там где-то рядом ходит макрос late (поищи его и тесты в исходниках и обсуждение в этом форуме в контексте DLR и dynamic), и если надо — творчески переработай. Кроме того похожие вещи поднимались не раз в контексте "duck typing". Насчёт глобального вывода типов, увы, направить никуда не могу. Как-то повелось считать что это зло, и я тут конформист, и даже в поиск на эту тему не хожу

А вот есть такая история: когда мы начали проект на Nemerle, то паралельно с освоением языка начали хреначить фреймворк "на все случаи жизни". Сейчас кажется что в xUSSR так все делают, ну или делают другое а всё равно фрейморк получается. Первым делом переизобрели множественное наследование (на макросах), как развитие темы — traits на интерфейсах (правда без синтаксиса, на маро-аттрибутах, синтаксис тогда ещё не умели), ещё какие-то мега-штуки много. В общем пытались натянуть Nemerle то на глобус то на C++, и удивительно получалось. Макросы однако.
Дотянули и до множественной специализации классов (причём два вида — на дженериках, и на наследниках от фиктивного типа), обломались на множественной специализации интерефесов (это годы тому назад было, и такая фича в Nemerle не поддерживалась, сейчас уже поддерживается), дошли до подстановки констант (в нашем случае регулярных выражений, но там даже сложнее чем, например, числовых). Венцом творения вроде была генерированная по описанию на лямбдах сериализация, причём один объект мог сериализоваться в сколько угодно разных XML и бинарных форматов. Это я только те штуки которые в силу немерянной крутости на слуху часто были, а мелких достижений наверное и не счесть.

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

И сейчас кажется что основные недостатки это то что linq идёт с <# #> а мог бы и без, то что иногда перед [] надо точку ставить, а лучше бы там вообще <> были и без точек, то что захваченную переменную в отладчике иногда искать надо в дебрях генерированных классов и имён, то что goto definition и find all references не ходит между Nemerle и C# проектами, то что автокомплит иногда тупит, и т.п.

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

NN>и чего бы я хотел видеть в Nemerle, а если точнее, то конкретизацию не при первом использовании, а при каждом

Ну, это так и задумывалось: выводится всегда самый конкретный тип. Это потому что при создании Немерле была цель как можно лучше работать с .NET, а в .NET шаблоны не приняты, в нем рулят генерики. А генерики лучше объявлять явно. В Немерле можно объявить, что функция генерик (как в С++), и тогда все будет работать четко.

К сожалению, эту фичу хотят удалить, и я не понимаю, почему.

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

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

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

DR>Было бы очень интересно увидеть пример.
https://github.com/rampelstinskin/ParserGenerator
Удачи сделать это без ДСЛ.
А уж сравниться по скорости без ДСЛ вообще не реально.
И это при том, что я там еще далеко не все запланированные оптимизации сделал.

Здравствуйте, <Аноним>, Вы писали:

А>Это миф, я не видел не одной программы на Немерле, которая былабы хотябы в два раза короче тойже программы на Шарпе.
А>(если включить либы Немерла, которые набивали темиже ручками).
Это не миф, а реальные цифры.

А>Что именно вы собрались валидировать на этапе компиляции ?
Очень много чего.

А>Влад вроде бросал ссылки ХМЛ, ХТМЛ и конечного автомата (правда по сорцам почемуто только картинка )
А>валидатора. Вроде как это рантайм, или ?
Или.

А>Приведите пример иного.
Сначала в этом разберись.

И еще научись формулировать свои мысли ясно. Ибо читать твои сообщения очень трудно. Ты случайно не родственник _Claus_?

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

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

F>>а с другой стороны, а что в C++? — ставить пробел перед закрывающей скобкой — обязаловка ныне — смешно же!
NN>эм... у тебя какие то древние сведения
Да ну? Древние это как? Есть реалии. C++11 — по факту, никем ещё не поддерживается, ближе всех gcc и clang, как я понимаю.
А вот написание — return Singleton<BuildInfo, LeakySingletonTraits<BuildInfo> >::get(); — суровая правда жизни.

У Немерле есть только один фатальный недостаток: он работает поверх CLR, а не на JVM или LLVM. После этого все остальные недостатки уже совершенно фиолетовы

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

VE>Лучше макросов всё, что может быть использовано вместо них. Так что вопрос стоило бы поставить иначе "что хуже макросов", потому что хуже ничего нет, но иногда без них не обойтись. И вот это "иногда" надо изолировать и делать наименее необходимым за счёт улучшения основного языка.
Макросы это и есть улучшение основного языка.
Причем вплоть до уровня, когда на языке можно решать задачу в терминах задачи.
Причем если у нас все есть макрос то "основной язык" у нас под ногами путаться перестает.
Что позволяет добиться максимальной выразительности, надежности и производительности.

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

_C_>+1. Метасвязки от Анонима — это, несомненно, будущее программирования.
Ты лучше ссылки на статьи дай.
Ибо своими словами ты еще ни кому, ни чего, ни разу не объяснил.

_C_>>это Аноним не дает. я бы дал.

VD>А он и ты не одно лицо случаем? Потом если ты знаешь о чем говорил Аноним, то и дал бы ссылку.

Братка это мой. не хочет тебе ссылку давать. говорит, съехал ты с темы

Автор: _Claus_
Дата: 13.07.12

, когда понял, что _Claus_ дело говорит.
Он все видит, братка мой, и передает тебе: "Серьезней надо быть, а если не прав, тем более".

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

I>"Метасвязки Анонима" — это зачёт

I>Кто в вики страницу забабахает?

Сложно что-ли сразу ссылку дать? В русской вики ничего не нашел. А как это чудо на инлишь проводится неизвестно.

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

WH>Просто по тому, что задачи, которые решаются в их терминах в природе практически не встречаются.

Они нужны для всевозможных оптимизаций, поскольку у каждой вычислительной модели есть N свойств и особенностей, при чем среди которых есть например сложность и порог вхождения. Это значит, что на простецком языке вроде JS или PHP простоватые программисты создают вагоны продуктов, а если их заставить делать "по правильному", то все эти продукты никогда не появятся, просто потому, что время переключения внимания,время погружения в проблему слишком велики, а скорости создания и усвоения информации ничтожно малы даже у гениальных людей.
Опаньки — это внезапно объясняет популярность JS, пхп и прочих вещей которые по твоему мнению "не нужны".

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

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

WH>Ты еще раз перечитай, что hi_octane пишет

Автор: hi_octane
Дата: 10.07.12

.

Любой евангелизм "а перечитай ..." есть тоже самое что и предложение попробовать наркоту. Если ты понял чего говорит VoidEx, то предполагается, ты на любое его заблждуение можешь эдакий тест оформить. Опаньки, а у тебя только "а перечитай ...". Вобщем как евангелисты вы с Владом где слева от нуля.

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

VE>А есть какой-то критерий, как понять, понял я макросы или нет? Ну кроме очевидного "в восторге от них — значит понял".

Встречный вопрос. Есть ли критерии по которым можно понять, что ты знаешь С++ или F#?

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

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

Вот только сегодня гугль принес ссылку на новый проект на немерле. Это какая-то студенческая работа из Италии. В ней не было бы ничего интересного кроме того, что по ней можно четко скзать, что человек создавший этот проект использовал Немерл как C#++. Фактически это добротный код C#-код с синтаксисом немерла и использованием готовых макросов (в частности, самый мощный C#-парсер созданный с использованием макроса Nemerle.Peg.

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

А вот проект нового генератора расширяемых парсеров для N2 разрабатываемый нами. В нем макросов куда больше чем другого кода. Парсер парсит себя. Вот текущее представление его "грамматики". Как говорится, попробуй на свой Агде (подставить любимый язык) написать более короткий и внятный код. Не выйдет ни в жизни. О производительности вообще даже и говорить не стоит (и это при том, что оптимизациями пока никто не занимался).

Единственное что можно сделать — это запилить собственный генератор парсеров (или воспользоваться имеющимся) и написать свой метакомпилятор. Но это будет в сто раз сложнее чем на Немерле с его макросами.

Все наши конкуренты идут похожим путем. И все сильно проигрывают в функциональности и/или производительности.

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

F>> Да ну? Древние это как? Есть реалии. C++11 — по факту, никем ещё не поддерживается, ближе всех gcc и clang, как я понимаю.
F>> А вот написание — return Singleton<BuildInfo, LeakySingletonTraits<BuildInfo> >::get(); — суровая правда жизни.
F> А можно узнать, с чем мэтр C++ DarkEld3r — не согласен?
F> С тем, что >пробел> — это реальная правда жизни, и никуда от неё не дется в C++11?
F> С тем, что я так устарел, а у нас каждый компилятор поддерживает C++11 в полном объеме?
F> С чем конкретно? Расскажи уж. Просвяти всех. Я лично буду тока рад.

Чуть меньше пафоса, пожалуйста.

Не согласен именно с такой "правдой жизни". Если подробнее, то с двумя вещами:
1. "ПОЛНАЯ поддержка" для такой мелочи не нужна. Её до сих пор ни у кого нет, вроде. Но частичная есть у многих. GCC поддерживает это с версии 4.3 которая вышла в марте 2008 года.
2. Есть "особенности компиляторов". Вижуал студия 2008 (это вообще 2007 год) нормально воспринимает такой код и без всякой поддержки новых стандартов. Может это некорректно, но работает и хоть это не лучший аргумент, но не всем нужна кросплатформенность.

Подробнее сразу отвечать не стал так как, во первых, в данной теме это офтопик. Во вторых, про это легко самому узнать при минимальных усилиях. Например, я вбил в гугл "gcc c++ right angle brackets" и перешел по первой же ссылке.
Из-за этого воспринял такие заявления как троллинг. Возможно, был не прав, хотя ответная реакция забавная.

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

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

Я не знаю что такое метасвязки. Возможно это очень круто. Приведи внятное описание, почитаем.

Я же говорил о доступных в реальной жизни методах абстракции. Фактически на сегодня общеприменимыми методами абстракции являются:
1. Функции/процедуры.
2. Типы (АТД).
3. Языки (ДСЛ/расширения ЯП).

Собственно ДСЛ-и потенциально дают наилучшее выражение задач. А генерация кода позволяет не меняя самих языковых абстракций как угодно менять реализацию.

Собственно говорить "лучшее" не очень правильно. Тут лучше подойдет слово "самая мощная", потому как языковые абстракции не бесплатны. Если задачи качественно решаются функциями или типами, то прибегать к ДСЛ-ям зачастую бессмысленны. Но если функции и типы пасуют, то ДСЛ-и, обычно являются отличной заменой.

Конечно, можно порассуждать о том, что и в языках без мета-подсистем можно создавать ДСЛ-и (флюент-интерфейс, реинтерпретация синтаксиса, и т.п.), но тут сразу встает проблема отсутствия возможности преобразовать код на ДСЛ в эффективный и корректный исполняемый код. Нормально это можно сделать только имея генерацию кода времени компиляции или динамической компиляцией/интерпретацией.

В общем, связка ДСЛ + метапрограммирование дает оптимальную абсракцию и гибкость.

Что же такое метасвязки и чем они лучше я не знаю, но с удовольствием послушаю объяснение.

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

VE>Очевидно, если я говорю "макросы плохо, лучше улучшать основной язык", то под улучшением я имею в виду явно не макросы, потому что я только что сказал, что макросы — плохо.
VE>А ты либо специально не читаешь собеседника, либо правда не понимаешь, но тогда это тревожный сигнал.
Я понял, что у тебя макрофобия.
Фобии нужно лечить.
А для этого нужно понять, что такое макросы.
Макросы это и есть инструмент, которым пользователь языка может изменить язык под свою задачу.
Причем ему не придется ждать, пока это сделает автор языка.
И он не помешает этим изменениям другим пользователям.
Более того изменения языка становятся просто библиотеками.
Которые можно подключать и отключать.

А все другие средства это создание фичей общего назначения для зыка общего назначения.
И это не работает.

Автор: hi_octane
Дата: 10.07.12

И работать не может.

А самое забавное в том, что все эти фичи общего назначения потом используются для создания ДСЛ.
Кривых. Тормозных. С хреновой диагностикой ошибок. ДСЛ.

VE>Понимаешь ли, if-else\for\while, например, могут быть реализованы на макросах, но сами по себе не макросы.

Тут готов поспорить. if-else,for,while — привычные, захардкоженные в большинство языков макросы. Ещё более неявный и привычный макрос — оператор доступа к членам '.' в C#, VB.NET, и т.д. Этот оператор ведёт себя совершенно по-разному в зависимости не только от типов стоящих слева и справа от него, но ещё и от реальных значений, если такие подразумеваются. Например в C# он может NullReferenceException кинуть, если слева reference-тип, с значением null. А может вообще ничего не сделать, если слева namespace и справа namespace. Причём за историю C# функциональность этого макроса расширяли, например в C#3 он научился находить Extension-методы, и не кидает NullReferenceException в случае если вызывается именно extension-метод.

Даже если вместо языка высокого уровня взять например ассемблер, то
ADD AX, [BP+2] — тоже сплошь состоит из макросов.

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

F> А я вот мегаспециальный синтаксис LINQ (в C#) и не использую вовсе — ну не вижу в нём проку и всё — вызвал экстеншн методы -> ну всё же то же самое и безо всякой фигни...

Честно говоря затрудняюсь найти аналоги в некоторых случаях. Одно дело простецкие .Where().Select() которых 90%. Но иногда замутишь какой-нить например from ... let ... let ... from. Такую смесь на одних экстеншенах писать, а потом читать и править однозначно сложнее чем на linq. Да и некоторые запросы к базе сначала на SQL обкатать, а потом на linq без фантазии транслировать тоже проще, чем выполнять "изложение на тему" в терминах экстеншн методов.

Здравствуйте, <Аноним>, Вы писали:

А>Тут согласен. В математике нет проваливается очень сильно,

И это заблуждение.

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

DR>Мне больше нравится аналогия Wolfhound'а: макросы, они как парашют — нужны редко, но когда нужны то без них никуда. А у меня первое ощущение при переключении на С++ — как быстро он компилируется!
Я тогда был маленький и глупый.
Сейчас я понимаю, что без них (я точнее без создания ДСЛ) нельзя сделать действительно качественную абстракцию.

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

KP>У Немерле есть только один фатальный недостаток: он работает поверх CLR, а не на JVM или LLVM. После этого все остальные недостатки уже совершенно фиолетовы

У машины может быть любой цвет при условии, что он черный (с) Генри Форд.

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

VE>Что тут читать. Я бы мог вспомнить про правила перезаписи, или про то, что какая-нибудь Agda, имея на руках
VE>

VE>proof : ∀{f g} → map f ∘ map g ≡ map (f ∘ g)
VE>

VE>могла бы проводить оптимизации (те же правила перезаписи, только с док-вом корректности), но ты же это макросами сейчас обзовёшь.

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

А ты можешь облизываться даже на них и продолжать использовать беззубый язык вроде С++ или Java, попутно философствуя тему "макросы не нужны".

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

VD>Судя по твоим словам можно предположить, что не понял. Даже можно более сильное утверждение сделать. Ты зачем-то ищешь обоснование для того чтобы не разбираться, что это такое и что это дает.

Прекращай телепатировать, меня WolfHound спросил, я ответил. Ответ вас не устроил и вы теперь убеждаете меня, что я не разобрался, так ещё и ищу основание для того, чтобы не разбираться. У вас уже совсем евангелизм способность читать поел.

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

VE>Прекращай телепатировать, меня WolfHound спросил, я ответил. Ответ вас не устроил и вы теперь убеждаете меня, что я не разобрался, так ещё и ищу основание для того, чтобы не разбираться. У вас уже совсем евангелизм способность читать поел.
И твой ответ содержал 0 аргументов.
И все твои последующие сообщения тоже не содержат ни одного аргумента.
Я, честно говоря, вообще не помню твоих сообщений с содержанием по существу. А не трёп с кучей голословных утверждений.

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

I>>Ты точно так же как и они агитируешь, отвечаешь вопросами на вопрос и уклоняешься от сложных вопросов. Пример
I>>http://rsdn.ru/forum/nemerle/4812833.1.aspx

Автор: hi_octane
Дата: 10.07.12

— вот внятный ответ на конкретный вопрос
I>>http://rsdn.ru/forum/nemerle/4811663.1.aspx

Автор: VladD2
Дата: 09.07.12

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

VD>Ну, да. Ребята на пути понимания макросов. Ты на этот пут только пытаешься ступить. Понять их тебе проще.

Если бы ты меньше додумывал и фантазировал, то давно бы понял о чем я говорю.

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

Ты зациклился на плюсах непосредственно языка и ничего кроме них не видишь и не хочешь видеть. Вероятно, это по причине того, что кроме как в компиляторе ты лично никгде всерьез не применял немерле. У тебя есть серьезный продукт не направленый на разработку и писаный на немерле ? Нет. Ты перевел разработку в крупной фирму на немерле ? Нет.

Объясни, что ты мне можешь объяснить, если у тебя вообще нет опыта в том, что меня интересует больше всего ?

>Для тебя это, похоже, пока что, пустые слова. Зато мелкая автоматизация вроде генерация диспозов тебе понятна. Вот тебе и кажется, что тебе что-то там внушают.

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

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

VE>Давай поподробнее. Ты утверждаешь, что любая фича общего назначения не нужна?
Я утверждаю, что для решения задачи нужны фичи позволяющие решать задачу в терминах задачи.
При этом фичи общего назначения чуть менее чем всегда не имеют ничего общего с терминами задачи.
Максимум на что они годятся это кривая и тормозная эмуляция фичей заточенных на задачу. А как правило и с этим справится не могут.
Чем ты в своём примере с туплом и занимался. Причем что характерно ты опять делал фичу общего назначения.

Но тебе же всё равно, что я напишу. Ты же любыми средствами пытаешься доказать что макросы зло.
При этом ни одного аргумента подтверждающего твою точку зрения ты до сих пор не привел.
Ну что? Покажешь класс? Изобразишь на агде https://github.com/rampelstinskin/ParserGenerator ?
Да так чтобы по скорости на несколько порядков не сливал. И синтаксис описания грамматики был не хуже.

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

VE>Весёлый ты парень, "поменяй-ка грамматику языка без метапрограмминга, что не можешь?"

Конечное веселый. Мы это можем сделать. И именно это позволяет описывать решение так как нужно для того чтобы оно не превратилось в говнокод.

VE>Однако исходники Агда-компилятора открыты, если что.

Счастливо по трахаться с правкой компилятора ЯОН-а. Даже если справишся с задачей, то твоя работа не будет никому нужна, так как использовать не стандартный клон ЯОН никто кроме тебя не будет.

VE>Так что могу.



VE>Правда почему-то менять компилятор напрямую некомильфо, а писать под него плагины — мегакрутая суперпупер технология.

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

VE>А ты ленивость реализуй, не куцую Lazy, а полноценную.

В Н2 — не вопрос.

Только ты опять ушел в свои заблуждения. Не нужна никому ленивость в общем случае. Те языки которые мы сейчас создаем вообще не имеют понятия "последовательность вычислений". Есть абстрактная модель, а модель вычислений подбирается такая какая нужна для проекта.

VE>А потом тотальность. На макросах. А потом сравни с той, что сделана напрямую.

Пойми же. На макросах и напрямую — это одно и то же. Я просто делаю язык и необходимую для него модель вычислений. Нужно будет повторить Агду 1 в 1 сделаем и это. Только вот не надо, так как Агда — это еще один универсальный язык (ЯОН). Причем кода на нем для решения задачи получается больше чем на языке без зависимых типов. А это уже серьезный симптом. Мы же хотим писать минимум кода.

VE>Забабахать систему, для которой идеально подходит Erlang.

И чем тебе в этом поможет Агда? А на макроса это как раз можно сделать.

VE>Это только в мире эльфов на языке программирования пишут код, который нужен только для языка программирования.

В мире эльфов пишут говнокод на Яве, а по вечерам ахают и прутся от крутости системы типов Агды.

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

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

VE>> Кстати макросы высшего порядка есть?

VD>Это бессмысленный вопрос вызванный непониманием сути макросов.

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

Здравствуйте, <Аноним>, Вы писали:

А>Agda дает доказательность. Из за этого объем текста и больше. Система типов Agda обеспечивает множество проверок, а чем больше средств обеспечения корректности кода тем больше текста и тем меньше надо делать тестов.
И что же доказывает система типов агды?
Все что она может это доказать что в программе нет некоторых классов ошибок.
Вся разница с явой в том что агда ловит несколько больше классов ошибок.

А>Н2 этого не обеспечивает да Н2 это особо и не надо. Макросы такого тоже не обеспечивают.
Н2 может круче.
На Н2 можно задать предметно ориентированную систему типов.
И ловить ошибки предметной области без тонны кода построенного на побочных эффектах.

А>Н2 это язык переписывания термов. Причем довольно сильно специализированный.
Слышал звон.

А>Например мне до сих пор не понятно как например на Н2 будет устраняться хвостовая рекурсия (в язках написанных на Н2).
Будет. Там еще много чего будет.

А>как будет решаться проблема неоднозначности синтаксисов.
На практике нет такой проблемы.
Она надумана.
А если учесть то что Н2 может менять грамматику в любой момент и мы можем в разных ветках if разный синтаксис...

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

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

_C_>Тото думаю Влад с WH ругаются, а оно вона чо
Ругаемся мы от того что ты с умным видом что-то говоришь. Но ссылок на научные работы не даешь.
И как следствие все твои слова выглядят как "бла-бла-бла".

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

В догонку

WH>>Но если сделать ДСЛ для того чтобы описывать языки это будет намного проще чем пилить код на ЯОН.

Ну вот допустим чем тебе eval "1 + 2 * 4" не ДСЛ?

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

_C_> Промолчу о нашумевших здесь "метасвязках Анонима" — и так понятно, что это МП надсущности.

"Метасвязки Анонима" — это зачёт

Кто в вики страницу забабахает?

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

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

WH>>>Но если сделать ДСЛ для того чтобы описывать языки это будет намного проще чем пилить код на ЯОН.

VE>>Пример такого ДСЛя и пример использования можешь привести?

VD>Nemerle.Statechart — ДСЛ для описания конечных автоматов.
VD>Nemerle.Xml — ДСЛ для генерации XML/HTML.
VD>Nemerle.WUI.Reactive — ДСЛ для описания интерактивного веб-интерфейса.

VD>А вообще, почитай Фаулера. У него не плохая книга этому вопросу посвящена.

Тоесть киллер фича Н2 валидация данных ?

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

WH>Здравствуйте, <Аноним>, Вы писали:

А>>Конечно это не миф, это целая мифология в стиле Немерле
А>>Из последних мне попадались на глаза генератор паролей, парсер хтмл тегов, евал выражений
А>>и везде там ниокаком в 10+ раз не идет речь, максимум в полтора раза, а о банальных стековых разборах
А>>выражений коим уже под 30 лет Немерлисты (почемуто?) даже не подозревают.
WH>А. Ясно. Навечно забаненный автор ультрошифрованного вернулся.

Не вернулся, а заглянул ненадолго
Я вижу тут успешно подхватили мой флаг "наш код в 10-1000 раз короче"
Правда вместо интересных разборов примеров, здесь защита — бан на 120 лет
Ну да ладно, вообщемто идеи все теже. С одним отличием — я понимал и понимаю экспериментальность ультракороткого языка,
о том что не смотря на какието вполне осязаемые приимущества в краткости программ, простоты грамматики,
язык останется экспериментальным, который не сможет хоть както потеснить Си и Ко
в продакшине. Всегда будет существовать программа "как надо писать" и та что
продается и работает в продакшине уже не один десяток лет, но ее код откровенный говнокод

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

DS>>>Лучше так: "Легендарные Метасвязки Анонима"
А>>Это они?
А>>http://webcache.googleusercontent.com/search?q=cache:USJi92_628cJ:logic.iph.ras.ru/vasyukov.tex+%D0%BC%D0%B5%D1%82%D0%B0%D1%81%D0%B2%D1%8F%D0%B7%D0%BA%D0%B8&amp;cd=20&amp;hl=ru&amp;ct=clnk&amp;gl=ru

M>Вот вы смеётесь, а между прочим люди на полном серьёзе думают, что написали что-то понятное и полезное. Примерно как я начал читать про алгебраические типы

Меня больше беспокоит молчание WH. Неужели он все понял ?! А если не понял, почему молчит. А если понял, что дальше? Везде тупик.

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

VE>>Пример такого ДСЛя и пример использования можешь привести?

VD>Nemerle.Statechart — ДСЛ для описания конечных автоматов.
VD>Nemerle.Xml — ДСЛ для генерации XML/HTML.
VD>Nemerle.WUI.Reactive — ДСЛ для описания интерактивного веб-интерфейса.

ДСЛ для КА это нормально, а дальше так себе. Есть — хорошо. Нету — тоже не плохо.

ну вот почти вторую неделю ковыряю Nemerle, по пути уже поглядел мельком на Roslyn поковырял Mono, и вот сижу и думаю, чего бы вбросить такого, что бы разгорелась жаркая дискуссия относительно Nemerle, а то я как посмотрю у вас тут одни сплошные потоки радости ). Но если чуть чуть серьезней, то понятно, что у Nemerle есть один большой "фатальный недостаток", но речь не о нем, хотелось бы узнать у сообщества, есть ли что-то что вам не совсем нравится в Nemerle, или совсем не нравится.
У самого есть несколько вопросов, но быть может все об этом и так знают и поэтому не стоит о них ни кому говорить.

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

NN>Но если чуть чуть серьезней, то понятно, что у Nemerle есть один большой "фатальный недостаток", но речь не о нем, хотелось бы узнать у сообщества, есть ли что-то что вам не совсем нравится в Nemerle, или совсем не нравится.

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

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

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

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

Вообще, уже была тема: Что вас раздражает или не нравится в Nemerle?

Автор: Ka3a4oK
Дата: 21.09.10

А>Основной недостаток это отсутствие родных библиотек. На библиотеки .нет ручками махать не надо, они совсем сделаны без макросов и значит нет основного преимущества немерли.

+1. Linq должен быть реализован как макробиблиотека, чтобы все разворачивалось и работало без всяких тормозов и замыканий. да и в остальном, в библиотеках N, нужен подход, основанный на описании в стиле UML. код писаться сам должен. иначе правы шарписты — выгоды в итоге сомнительны. если только не пишешь что-то очень хитрое. правда CodingUnit что-то похожее делал, никак руки не дойдут пощупать, насколько его разработка юзабельна, как основа системы.

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

DR>Вообще, уже была тема:
спасибо как раз то что я плохо искал )))
щас сформулирую свои вопросы на основе прочитанного в той теме

большая часть той темы посвящена очень важной проблеме просто "фатальному недостатку"
не возможно написать

a=-1;

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

using System;
public class Program
{
    public static Main() : void
    {    
        def foo(a, b) {
            a + b
        };
        Console.WriteLine($"$(foo(1, 2))$(foo(1.0, 2.0))$(foo(1, 2.0))");
    }
}

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

using System;
public interface IFoo
{
    foo (x : IFoo) : IFoo*IFoo;
}

public class Foo : IFoo
{
    public foo (x : IFoo) : IFoo*IFoo 
    {
        (this, x)
    }

    public foo(x : Foo) : Foo*Foo
    {
        (this, x)
    }    
}

public class Bar : IFoo
{
    public foo(x : IFoo) : IFoo*IFoo
    {
        (x, this)
    }

    public foo(x : Bar) : Bar*Bar
    {
        (x, this)
    }
}

public class FooBarExtentions
{
    public static foo(this b : Bar, f : Foo) : Foo*Bar
    {
        (f, b)
    }
    public static foo(this f : Foo, b : Bar) : Foo*Bar
    {
        (f, b)
    }
}

public class Program
{
    
    public static Main() : void
    {    
        def foo(a, b) {
            a.foo(b)
        };
        Console.WriteLine($"$(foo(Bar(), Bar()))$(foo(Foo(), Foo()))$(foo(Bar(), Foo()))");
    }
}

казалась бы проблема решена, но почему то от ее решения мне становится грустно
nemerle сгенерировал для функции foo следующий код\

private static Tuple<IFoo, IFoo> _N_foo_4280(IFoo a, IFoo b)
{
    return a.foo(b);
}

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

#include <utility>
#include <iostream>

template<typename T1, typename T2>
auto foo(T1 x, T2 y) -> decltype(std::forward<T1>(x) + std::forward<T2>(y))
{
    return std::forward<T1>(x) + std::forward<T2>(y);
}

int main()
{
    std::cout << foo(1, 2) << foo(1.1, 2.2) << foo(1, 2.2);
    std::cin.get();
}

знающие люди увидят, что здесь на самом деле будет не одна шаблонная функция, а три
компилятор С++ проинстанцирует 3 специализации функции foo для каждого сочетания шаблонных параметров,
так же кто то скажет, что это не совсем вывод типов и что это вообще шаблоноговнокод,
но он очень хорошо показывает то о чем я хочу сказать
и чего бы я хотел видеть в Nemerle, а если точнее, то конкретизацию не при первом использовании, а при каждом
...
продолжение следует

C> В Немерле можно объявить, что функция генерик (как в С++), и тогда все будет работать четко.
C>К сожалению, эту фичу хотят удалить, и я не понимаю, почему.

Не понял, убрать функции параметризованные типом или что?

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

STD>Не понял, убрать функции параметризованные типом или что?

Локальные функции, параметризированные типом.

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

private static Tuple<IFoo, IFoo> _N_foo_4399(IFoo a, IFoo b)
{
    return a.foo(b);
}

компилятору, следовало бы генерировать 3 функции, для каждого применения функции foo
примерно так как это делает компилятор С++, но начал я говорить о глобальном выводе типов, а не о локальных функциях, а тут проблемы гораздо глубже, для того что бы их понять
можно обратить внимание на следующий код

using System;
public class Program
{
    public static Main() : void
    {    
        def foo(a, b) {
            a + b
        };
        Console.WriteLine("Hi, Bob!!!");
    }
}

как можно заметить, я все еще не выхожу за рамки локальных функций, потому что корни проблемы видны даже на это уровне,
и суть этих корней заключается в том, что если функция не применена то у нас ни чего не скомпилируется, потому что компилятор не может ее конкретизировать,
и как, если я не ошибаюсь, говорил Влад, nemerle пытается вывести наиболее конкретный тип, а не наиболее общий,
ну т.е. это вроде как by design и так и должно быть, но мне кажется это опять же лукавство,
by design тут не причем, тут проблема в том, что на выходе компилятора nemerle должна быть .net сборка,
а в .net просто нету этого общего типа, который мог бы быть выведен для оператора +
и вот уже эта проблема намного шире чем локальные функции, и в первую очередь она делает не возможным глобальный вывод типов
в .net сборке у функции должен быть указан тип, т.е. мы не можем иметь в сборке функцию с не конкретизированным типом.

исходя из всего сказанного можно было бы предложить несколько вариантов решения проблемы.
1) который ни чего не решает, но тем не менее его тоже необходимо рассмотреть.
если локальная функция не используется, ее вообще не должно быть в сборке, я думаю это вполне реализуемо, уже другой вопрос, что это нафиг ни кому не нужно, так как писать функцию, которая ни где не используется, глупость со стороны разработчика.
но ведь смотрите, к чему приводит отсутствие этой фичи.
допустим мы временно хотим закомментировать место использования функции, для того что бы попробовать другую реализацию допустим.
nemerle же вынуждает нас комментировать и саму функцию, хотя спокойно мог бы локальную то функцию и выбросить, пускай и выдав варнинг.
2) более сложный способ как мне кажется, и я не до конца понимаю как его реализовать, но тем не менее, он присутствует в хаскеле,
и называется классы типов, я реализовывал нечто вроде классов типов в С++ на шаблонах, на счет .net языков не уверен, что это реализуемо,
и в любом случае скорее всего приведет к тому что придётся пересматривать систему типов полностью.
так же потребуется вносить изменения в вывод типов, который должен будет выводить наиболее общий тип,
и подставлять его в реализацию функции в сборке,
а при каждом использовании, нужно будет инстанцировать конкретный тип,
3) способ я бы назвал компромиссным, т.е. мы не трогаем систему типов и стараемся остаться в рамках .net'а
заключается он в том, что в сборку подставляется не конкретный тип, а сгенерированный на лету интерфейс заглушка,
т.е. мы не пытаемся в месте объявления функции вывести тип, мы генерируем интерфейс заглушку и помечаем его каким либо атрибутом, который скажет нам что этот интерфейс необходимо конкретизировать в месте использования, таким образом в наружу у нас торчат публичные интерфейсы заглушки, которые точно так же можно использовать из .Net написав в ручную реализацию этих интерфейсов, а в компиляторе nemerle мы при встрече интерфейса с указанным атрибутом, мы пытаемся его конкретизировать в месте использования, и сгенерировав скрытую его реализацию.

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

module Main where
foo a b = a + b
main = putStrLn (show (foo 1 2) ++ show(foo 1.0 2.0) ++ show(foo 1 2.0))

без проблем компилируется
и выводит для функции foo следующий тип

foo :: forall a. GHC.Num.Num a -> a -> a -> a

и теперь второе лукавство
>даже в хаскеле указание типов считается правилом хорошего тона
для функции foo ведь можно указать тип

foo :: Int -> Int -> Int

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

foo :: (Num a) => a -> a -> a

к сожалению nemerle не хаскель )))

PS: но я бы подумал, над предложенными мной способами обойти эту проблему

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

C>В Немерле можно объявить, что функция генерик (как в С++), и тогда все будет работать четко.
ну не совсем )

using System;
public class Program
{
    public static Main() : void
    {    
        def foo[T](a : T, b : T) : T {
            a + b
        };
        Console.WriteLine($"$(foo(1, 2))$(foo(1.0, 2.0))$(foo(1, 2.0))");
    }
}

ты не заставишь работать даже с генериками, это проблема генериков

+ я в том посте таки и предлага выводить самый конкретный тип, но не при первом использовании, а при каждом
в место 1 локальной функции генерировать несколько

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

да и с генериками врятли можно реализовать что то лучше чем

using System;
public interface IFoo
{
    foo (x : IFoo) : IFoo*IFoo;
}

public class Foo : IFoo
{
    public foo (x : IFoo) : IFoo*IFoo 
    {
        (this, x)
    }

    public foo(x : Foo) : Foo*Foo
    {
        (this, x)
    }    
}

public class Bar : IFoo
{
    public foo(x : IFoo) : IFoo*IFoo
    {
        (x, this)
    }

    public foo(x : Bar) : Bar*Bar
    {
        (x, this)
    }
}

public class FooBarExtentions
{
    public static foo(this b : Bar, x : IFoo) : IFoo*Bar
    {
        (x, b)
    }
    public static foo(this f : Foo, x : IFoo) : Foo*IFoo
    {
        (f, x)
    }
}

public class Program
{
    
    public static Main() : void
    {    
        def foo[T](a : T, b : T) where T : IFoo {
            a.foo(b)
        };
        Console.WriteLine($"$(foo(Bar(), Bar()))$(foo(Foo(), Foo()))$(foo(Bar(), Foo()))");
    }
}

и в итоге получить

private static Tuple<IFoo, IFoo> _N_foo_4399<T>(T a, T b) where T: IFoo
{
    return a.foo((IFoo) b);
}

что опять же не совсем то, что хотелось бы увидеть
все равно вызовутся не самые конкретные фукнции классов Foo Bar
и возвращаемый тип опять же будет не конкретным
в общем генерики особо ни чем не помогают

NN>PS: но я бы подумал, над предложенными мной способами обойти эту проблему

Боюсь, тебе будет трудно поверить, что причина описанных проблем кроется не в N, а в идеологии .Net. В ней замыкания принято иметь как одну функцию, и изменение этого вызовет массовую истерию. еще в .Net нет общего числового типа для int и double. и т.д. и т.п.

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

NN>ты не заставишь работать даже с генериками, это проблема генериков

В F#-е заставишь. Никто не заставляет генерить одну generic-реализацию для всех случаев.

Здравствуйте, _Claus_, Вы писали:
_C_>Боюсь, тебе будет трудно поверить, что причина описанных проблем кроется не в N, а в идеологии .Net.
вот а я уж думал, неужели придётся самому это писать )))
без условно самый главный недостаток nemerle это .Net
все было бы проще если бы многие фичи вывода типов присутствовали не на уровне языков, а на уровне CIL
конкретизация типов должна присутствовать где то на уровне JIT, а на уровне компиляторов языков должен присутствовать вывод типов который выводит наиболее общий тип

Здравствуйте, Tissot, Вы писали:
> Никто не заставляет генерить одну ...реализацию для всех случаев.
об этом и речь

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

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

NN>без условно самый главный недостаток nemerle это .Net

дык бери Scala. он и с типами работает получше в плане автоприведений.

NN>все было бы проще если бы многие фичи вывода типов присутствовали не на уровне языков, а на уровне CIL
NN>конкретизация типов должна присутствовать где то на уровне JIT, а на уровне компиляторов языков должен присутствовать вывод типов который выводит наиболее общий тип

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

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

_C_>вывод типов в F# есть, и в С# тоже зачатки. так что они решают на уровне компилятора. до JIT. это норм. решение. согласующееся с общей идеологий .Net.
Эм — насколько я понял, в F# — совершенно тупые ограничения, ограниченные исключительно ленью разработчиков, нет?

PS: не помню, как-то пытался какую-то приблуду поднять на F#, чего-то ей не хватало, что-то вроде F#Tools, на подобии T4Toolbox — только нифига не было написано — но далеко не сразу понял в чём беда. А, ну и традиционно с моей русской локалью не дружило, хотя венда и язык разумеется инглиш. Это не траблы языка — просто столкнулся нинароком. Это низа ни в пользу — однако, не видел программ на C# требующих тулбоксов... Пруфлинк не дам, извиняюсь сразу. Скорее пишу эмоции.

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

Ох, "Это низа ни в пользу — однако" -> "Это ниразу не в минус языку".

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

F>а с другой стороны, а что в C++? — ставить пробел перед закрывающей скобкой — обязаловка ныне — смешно же!
эм... у тебя какие то древние сведения

по всему остальному я пришел к nemerle поглядев erlan, но пришел не как к промышленному языку,
а как к языку на котором можно реализовать другой язык программирования,
потому что erlang имеет один "фатальный недостаток" динамическую типизацию + кучу проблем by design,
конечно все эти проблемы меркнут перед его плюсами, но его плюсы не в языке, а в платформе, и по этому без условно для меня
самый главный недостаток nemerle .net, все остальное это уже конечно придирки и пожелания не более,
я не говорю что из-за каких либо приведенных мной недостатков кому то надо отказаться от nemerle и использовать что либо другое

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

erlang — отличная платформа, для тех кто его понимает, хочет использовать и знает как использовать. У нас на Украине есть один банк который вроде как его использует — отклик банкоматов при этом просто отвратительный. Эм. Не факт что там вообще эрли учавствует. Просто к слову, пришлось.
Я вот в последнее время всё больше озадачиваюсь созданием кластера на .NET. Да, пусть это 5 разношерстных WCF сервисов, но это единый комплекс, и для одного из них идеальный вариант "обходить" вызовы сервиса и общаться с оборудованием напрямую, если это происходит на одной машине. Технически — вообще проблем нет. Но и фреймворков готовых предоставить минимальную инфраструктуру — тоже нет. Azure — это в принципе другие, и не подходит, и близко не имеет того что необходимо, увы. Решения судя по гуглу где-то лишь смежные есть, но за немалое бабло, и не факт что оно вообще подходит.
Это я всё к тому — что, всё всегда в наших руках. Erlang — платформа, не только язык, — но сказать, что она универсальна — разумеется тоже никак нельзя.

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

_C_>вывод типов в F# есть, и в С# тоже зачатки. так что они решают на уровне компилятора. до JIT. это норм. решение. согласующееся с общей идеологий .Net.

F# сдулся,

open System

let foo a b = a + b

let main() = 
    Console.WriteLine("{0}{1}{2}", (foo 1 2), (foo 1.0 2.0), (foo 1 2.0))

main()

проблемы все те же, конкретизация в момент первого использования

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

_>И сейчас кажется что основные недостатки это то что linq идёт с <# #> а мог бы и без, то что иногда перед [] надо точку ставить, а лучше бы там вообще <> были и без точек, то что захваченную переменную в отладчике иногда искать надо в дебрях генерированных классов и имён, то что goto definition и find all references не ходит между Nemerle и C# проектами, то что автокомплит иногда тупит, и т.п.
А я вот мегаспециальный синтаксис LINQ (в C#) и не использую вовсе — ну не вижу в нём проку и всё — вызвал экстеншн методы -> ну всё же то же самое и безо всякой фигни...

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

F> Это я всё к тому — что, всё всегда в наших руках. Erlang — платформа, не только язык, — но сказать, что она универсальна — разумеется тоже никак нельзя.
реализовать платформу подобную Эрлангу на .Net очень трудно by design слишком разные цели преследовались при их разработке, + в .net целый ворох фич, которые по сути не нужны для подобной платформы, но этот ворох так и будет волочиться за любым языком на этой платформе словно парашют.

примеры приводить сложно, но сходу могу сказать допустим о подгрузке кода на лету, ну т.е. как подгрузке, загрузить сборку то нет проблемы, дак вот тока выгрузить старую можно только грохнув весь домен

то же самое и с потоками Эрланга, с обменом сообщениями, с отсутствием шаред данных, отсутствием мутабельных данных и тд и тп

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

_C_>>вывод типов в F# есть, и в С# тоже зачатки. так что они решают на уровне компилятора. до JIT. это норм. решение. согласующееся с общей идеологий .Net.

NN>F# сдулся,

Уверен, что именно F#?

let inline foo a b = a + b

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

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

Здравствуйте, Tissot, Вы писали:
T>Уверен, что именно F#?

module Main where
main = putStrLn (show (foo 1 2) ++ show(foo 1.0 2.0) ++ show(foo 1 2.0))
    where foo = \a b -> a + b

ага )

The inline modifier can be applied to functions at the top level, at the module level, or at the method level in a class.

но уже лучше )))
правда немного не то, но лучше

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

T>>Уверен, что именно F#?

NN>

NN>module Main where
NN>main = putStrLn (show (foo 1 2) ++ show(foo 1.0 2.0) ++ show(foo 1 2.0))
NN>    where foo = \a b -> a + b
NN>

NN>ага )


NN>

NN>The inline modifier can be applied to functions at the top level, at the module level, or at the method level in a class.

Что есть — то есть

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

NN>ну вот почти вторую неделю ковыряю Nemerle, ...

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

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

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

F>Да мне не нужен аналог, мне нужна платформа решающая типичные проблемы кластера
Извини, не втему... Parallel C# видел? К их рантайму прикрутить dsl на nemele....

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

F>>Да мне не нужен аналог, мне нужна платформа решающая типичные проблемы кластера
D>Извини, не втему... Parallel C# видел? К их рантайму прикрутить dsl на nemele....
Видимо совсем не в тему или я ничего не понял. При чём тут это?

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

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

F>>>Да мне не нужен аналог, мне нужна платформа решающая типичные проблемы кластера
Уточни, pls, о каких типичных проблемах кластера идёт речь?

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

F>>>>Да мне не нужен аналог, мне нужна платформа решающая типичные проблемы кластера
D>Уточни, pls, о каких типичных проблемах кластера идёт речь?
Ну я же писал выше, — автоматизация установки / обновления узлов, сервисы, для которых важно, что бы они были одной версии — предотвращать одновременную работу разных версий, для другой части важно иметь гибкий "роутинг", т.е. приоритет может иметь локалхост, но не везде это актуально. Конфигурирование — вероятно, если несколько узлов будут работать с одной конфигурацией, а другие — с другой — тоже как бы не гуд. Короче ничего сверхъестественного не нужно, но инфрастуктура нужна.

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

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

F>>>>>Да мне не нужен аналог, мне нужна платформа решающая типичные проблемы кластера
D>>Уточни, pls, о каких типичных проблемах кластера идёт речь?
F> Ну я же писал выше, — автоматизация установки / обновления узлов, сервисы, для которых важно, что бы они были одной версии — предотвращать одновременную работу разных версий, для другой части важно иметь гибкий "роутинг", т.е. приоритет может иметь локалхост, но не везде это актуально. Конфигурирование — вероятно, если несколько узлов будут работать с одной конфигурацией, а другие — с другой — тоже как бы не гуд. Короче ничего сверхъестественного не нужно, но инфрастуктура нужна.

пока не понятно 2 вещи — причем тут нет? и чем плох грид?
из за нета потери быстродействия в математике в 1,5-3 раза по сравнению с с++(сам делал тесты), так что возможно проще не заморачиваться, а писать на С++?

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

А>пока не понятно 2 вещи — причем тут нет? и чем плох грид?
Нет при том, что всё сервисы на нете.
Теперь я не понял, — что значит чем плох грид?

А>из за нета потери быстродействия в математике в 1,5-3 раза по сравнению с с++(сам делал тесты), так что возможно проще не заморачиваться, а писать на С++?
Совершенно не проще, наоборот от C++ уходим, наконец-то безвозвратно.

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

А>>из за нета потери быстродействия в математике в 1,5-3 раза по сравнению с с++(сам делал тесты), так что возможно проще не заморачиваться, а писать на С++?
F> Совершенно не проще, наоборот от C++ уходим, наконец-то безвозвратно.
А что за задача?

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

F>> Совершенно не проще, наоборот от C++ уходим, наконец-то безвозвратно.
А>А что за задача?
Инфраструктура + бизнес логика + шлюзы к инородным системам. Ничего такого, где C++ был бы необходим.

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

На взброс думаю не потянет, но все же
Один из недостатков это связь с System Reflection Emit и в следствии чего нет нормальной работы в Mono.

Здравствуйте, <Аноним>, Вы писали:

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

А>На взброс думаю не потянет, но все же
А>Один из недостатков это связь с System Reflection Emit и в следствии чего нет нормальной работы в Mono.
hardcase выделяет работу с Reflection.Emit в отдельный класс/сборку — будет возможность делать сменные backends

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

F>Здравствуйте, Аноним, Вы писали:

F>>> Совершенно не проще, наоборот от C++ уходим, наконец-то безвозвратно.
А>>А что за задача?
F> Инфраструктура + бизнес логика + шлюзы к инородным системам. Ничего такого, где C++ был бы необходим.
Тут согласен. В математике нет проваливается очень сильно, а в остальном провал в 1,5 раза не о чем учитывая ложность написания на С++, функционал существенно важнее скорости.

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

D>Здравствуйте, <Аноним>, Вы писали:

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

А>>На взброс думаю не потянет, но все же
А>>Один из недостатков это связь с System Reflection Emit и в следствии чего нет нормальной работы в Mono.
D>hardcase выделяет работу с Reflection.Emit в отдельный класс/сборку — будет возможность делать сменные backends

Там не хватает поддержки extern alias , чтобы это дело завершить.

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

D>hardcase выделяет работу с Reflection.Emit в отдельный класс/сборку — будет возможность делать сменные backends
Н2? Смысла в сменных бакэндах по большому счету нет. Так как переносимость зависит в основном от библиотек. Только как вариант дать поиграться джавистам. Пусть завидуют.

Здравствуйте, <Аноним>, Вы писали:

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

D>>hardcase выделяет работу с Reflection.Emit в отдельный класс/сборку — будет возможность делать сменные backends
А>Н2?

Нет, в текущей версии nemerle — 1.x.
А>Смысла в сменных бакэндах по большому счету нет. Так как переносимость зависит в основном от библиотек. Только как вариант дать поиграться джавистам. Пусть завидуют.
Всё зависит от стандартной библиотеки...
Дальше можно сделать как в haxe — есть стандартная библиотека + возможность использовать возможности платформы
В теории можно даже в нэйтив компилировать... (Как в том же моно)...

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

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

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

DS>Здравствуйте, <Аноним>, Вы писали:

А>>Тут согласен. В математике нет проваливается очень сильно,

DS>И это заблуждение.

Это тесты мои. Текст переносился с С++ на шарп. исходник был примерно 10К. никаких классов и внешних библиотек. Провал в скорости был более 3 раз. время работы для С++ минут 10, так что запуск и т не играл роли. Программа работала в консоли и выдавали время начала, время окончания и результат.

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

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

DS>>Здравствуйте, <Аноним>, Вы писали:

А>>>Тут согласен. В математике нет проваливается очень сильно,

DS>>И это заблуждение.

А>Это тесты мои. Текст переносился с С++ на шарп. исходник был примерно 10К. никаких классов и внешних библиотек. Провал в скорости был более 3 раз. время работы для С++ минут 10, так что запуск и т не играл роли. Программа работала в консоли и выдавали время начала, время окончания и результат.

Угу — и где нибудь struct байт так на 200 через стек передевали наверное в цикле ? Неудивительно.
В моих задачах шарп сливает не больше 25%.

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

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

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

DS>>>Здравствуйте, <Аноним>, Вы писали:

А>>>>Тут согласен. В математике нет проваливается очень сильно,

DS>>>И это заблуждение.

А>>Это тесты мои. Текст переносился с С++ на шарп. исходник был примерно 10К. никаких классов и внешних библиотек. Провал в скорости был более 3 раз. время работы для С++ минут 10, так что запуск и т не играл роли. Программа работала в консоли и выдавали время начала, время окончания и результат.

А>Угу — и где нибудь struct байт так на 200 через стек передевали наверное в цикле ? Неудивительно.
А>В моих задачах шарп сливает не больше 25%.

никаких структ, классов, стандартных библиотек и т д

только переменные, массивы, циклы, условия, передавал в функции только переменные, никаких структур.
больше математику и нет не скрещиваю

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

А>Это тесты мои. Текст переносился с С++ на шарп. исходник был примерно 10К. никаких классов и внешних библиотек. Провал в скорости был более 3 раз. время работы для С++ минут 10, так что запуск и т не играл роли. Программа работала в консоли и выдавали время начала, время окончания и результат.

Отстают массивы. Скорее всего тестах были матричные вычисления или что-то вроде того. Кроме того много зависит от версии фрэймворка, типа процессора, версии и типа компилятора С++ и т.п.

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

VD>Отстают массивы. Скорее всего тестах были матричные вычисления или что-то вроде того. Кроме того много зависит от версии фрэймворка, типа процессора, версии и типа компилятора С++ и т.п.

GCC 4.7
NET 4
почти матричные, дифуры.
core 5i sse3

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

А>GCC 4.7
А>NET 4
А>почти матричные, дифуры.
А>core 5i sse3

С матрицами в дотнете все плохо. Если GCC умеем применить sse, то разрыв будет еще больше. А так, арифметика примерно в то же время вычисляется.

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

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

VD>Отстают массивы. Скорее всего тестах были матричные вычисления или что-то вроде того. Кроме того много зависит от версии фрэймворка, типа процессора, версии и типа компилятора С++ и т.п.

Я недавно один микробенчмарк затеивал, так народ обнаружил, что от версии .net'а действительно зависит: чем выше версия, тем медленнее.
http://thedeemon.livejournal.com/49226.html?thread=581962#t581962
И разница между x64 и x86 в .net очень заметная получилась.

А на sse в gcc особо рассчитывать не приходится, он только очень примитивные циклы умеет векторизовать.

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

К сожалению, могу лишь только подтвердить. При том, не смотря, на то что в блогах хвастались что x64 jit умеет такое, что не умеет x86 — x86 jit стабильно выигрывает на любой платформе (в смысле windows x86/x64). У них разная кодовая база для JIT — её обещают не первый год объеденить. Вот уже .NET 4.5 идёт — но судя по всему, они до сих пор разные.
Но — всё же зависит от задачи. Мне чего-то кажется, что от векторизации циклов толку в прикладном коде... ммм... ну не про математику — около нуля (или я ошибаюсь?). А вот я наблюдал картинку, когда код при наличии клиентского бэкграунд GC (в .NET4) начинает раза в 3-4 быстрее шуршать (на core 2 duo), против явного высвобождения памяти. Понятно, что с GC памяти тратится больше, но не катастрофически (мег на 20).

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

F> К сожалению, могу лишь только подтвердить. При том, не смотря, на то что в блогах хвастались что x64 jit умеет такое, что не умеет x86 — x86 jit стабильно выигрывает на любой платформе (в смысле windows x86/x64).

В моем тесте получилось наоборот — x64 быстрее. Но это очень узкий микробенчмарк, об общей производительности он не говорит.

F> Но — всё же зависит от задачи. Мне чего-то кажется, что от векторизации циклов толку в прикладном коде... ммм... ну не про математику — около нуля (или я ошибаюсь?).

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

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

DM>Все правильно. Изначальная задача, вдохновившая мой бенчмарк, — это фрагмент видеокодека. В основном сравнивал компиляторы С++, а C# там чисто из любопытства.
И какой счет?

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

А>И какой счет?

См. пост по приведенной ссылке. Если говорить про C# vs C++, то в этом тесте C# (на х64) получился шустрее, чем старые С++ компиляторы, но медленне, чем свежие. Однако даже хорошие С++ компиляторы в разы отстают от ручной векторизации.

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

_>А оно всё оказалось не очень-то надо в реальной жизни, и большая часть этих наворотов была к концу проекта просто забыта в дебрях стремительно устаревающего кода и использовалась только для того чтобы в NUnit зелёных кружочков табунами гонять.



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

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

I>А что конкретно из макросов пригодилось, ну, кроме логирования ?

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

Макрос — это ведь не хак который позволяет сделать, то что без них красиво не сделать. Это еще и принцип абстракции. Мощнейший принцип. Когда ты почувствуешь, что можешь менять дизайн всей системы не переделывая кон реализации, а только изменив генератор кода для своего ДСЛ-я, то все эти ФВП, ПМ, каринг, ООП, ... тебе покажутся мелочами.

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

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

I>>А что конкретно из макросов пригодилось, ну, кроме логирования ?

VD>А ты сам как-нить попробуй на досуге.

Евангелизм такой мутной воды принципиально не рассматриваю, так что не трать силы.

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

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

Мне больше нравится аналогия Wolfhound'а: макросы, они как парашют — нужны редко, но когда нужны то без них никуда. А у меня первое ощущение при переключении на С++ — как быстро он компилируется!

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

_>А оно всё оказалось не очень-то надо в реальной жизни, и большая часть этих наворотов была к концу проекта просто забыта в дебрях стремительно устаревающего кода и использовалась только для того чтобы в NUnit зелёных кружочков табунами гонять.
Это все по тому, что вы начали наворачивать фичи на язык общего назначения.
Это ошибка.
Нужно было делать ДСЛ для задачи.
Тогда бы у вас и кода было бы много меньше.
И макры не пошли бы в мусор.

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

WH>Я тогда был маленький и глупый.
WH>Сейчас я понимаю, что без них (я точнее без создания ДСЛ) нельзя сделать действительно качественную абстракцию.

То есть, раньше ты лишь изредка использовал макросы, но позже понял, что создавал при этом недостаточно качественные абстракции? Было бы очень интересно увидеть пример.

Лично я сейчас использую Немерле как "C# с вариантами". Мой рабочий репозиторий состоит из двух частей: прикладной на плюсах и исследовательской на Немерле. Исследовательская часть больше: в ней прототипируются алгоритмы, собирается статистика и подбираются параметры.

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

WH>https://github.com/rampelstinskin/ParserGenerator
WH>Удачи сделать это без ДСЛ.
WH>А уж сравниться по скорости без ДСЛ вообще не реально.
WH>И это при том, что я там еще далеко не все запланированные оптимизации сделал.

Ясно. Жаль, что этот пример такой нетипичный. Всё таки, очень мало людей пишет парсеры.

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

I>Евангелизм такой мутной воды принципиально не рассматриваю, так что не трать силы.

Ага. Всегда проще наклеить ярлычок вроде "евангилизм", чем в чем-то разобраться и попробовать на практике.

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

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

DR>Мне больше нравится аналогия Wolfhound'а: макросы, они как парашют — нужны редко, но когда нужны то без них никуда.

Он уже ответил на это сам. И это уже слова не мальчика, но мужа (с)

ЗЫ


Реально я не знаю как объяснить тем кто не проникся на практике, то что дают макросы. Это надо просто прочувствовать. Хотя возможно я просто пока не могу качественно это сформулировать.

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

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

Немерл 1.х не идеален и добиваться своей цели в нем довольно сложно. Надеюсь, что Н2 позволит упростить эту задачу в разы.

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

DR>Ясно. Жаль, что этот пример такой нетипичный. Всё таки, очень мало людей пишет парсеры.

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

Идеология получения правильных абстракций — продумываешь модель своей задачи (описание задачи в виде некой структуры данных или языка). Продумываешь язык описывающий модель (ДСЛ). Пишешь генератор из модели в код или интерпретатор. Описываешь задачу на полученном ДСЛ. Рефакторишь генератор/интерпретор так чтобы получить нужное качество прдукта. Если нужно развиваешь или рефакторишь ДСЛ. Повторяешь последние пункты до получения оптимального результата.

Язык (ДСЛ) обеспечивает максимальную близость абстракции к решаемой задаче. Генератор обеспечивает независимость реализации от возникающих проблем и позволяет не идти на поводу у "инструмента".

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

Собственно о чем я и говорил.
Когда вы перестали расширять язык общего назначения фичами общего назначения и начали делать конкретные решения у вас все начало получаться.
Но дзен вы постигли не до конца.
Следующая ступень в просветлении это понимание того что если бы вы изначально не использовали ЯОН то все было бы еще проще.
Проблема в том что в данный момент ДСЛ даже на Н1 делать довольно тяжело. Н2 исправит эту проблему.

WH>Собственно о чем я и говорил.
WH>Когда вы перестали расширять язык общего назначения фичами общего назначения и начали делать конкретные решения у вас все начало получаться.

Ну да, так это я и называю "перестали фреймворк писать".

WH>Но дзен вы постигли не до конца.
WH>Следующая ступень в просветлении это понимание того что если бы вы изначально не использовали ЯОН то все было бы еще проще.
WH>Проблема в том что в данный момент ДСЛ даже на Н1 делать довольно тяжело. Н2 исправит эту проблему.

Тут просто нехватка понятий. Обычно под ДСЛ понимают именно языковые конструкции, ключевые слова там новые и т.п. В этом случае у нас от ДСЛ не так и много было — readlock, writelock, ещё что-то такое-же простое. А получилось что язык вообще стал отступать, под давлением всяких "неявных" реализаций. Это уже даже не DSL а Domain Specific Runtime что-ли. И чем дальше тем сильнее мы уходили от декларативного программирования, всё больше полагаясь на магию автогенерации, завязанную на совершенно нетрадиционные вещи — имена классов и namespace'ов, объявленные но не реализованные интерфейсы, тот же тип поля SyncRoot, значение константы Offset (там была магия с DateTime на разных системах). Что было очень неожиданно, так как первое правило которое мы сами себе придумали — это что код не должен браться из ниоткуда. Типа там нам самим будет непонятно, если не будет аттрибута [AutoDispose] хотя-бы на классе, а лучше на мемберах. А оказалось наоборот, что аттрибуты тоже код, и если избавляться по-возможности и от них — то жить проще.

Да, и ещё интересный момент — связность кода за счёт иерархий наследования реализации стала сильно падать. Сейчас мне даже кажется что virtual и override это неправильный костыль, и можно выкатить язык на одних только интерфейсах и с макропрограммированием, и будет epic win. Но пока не потренируюсь на прототипе, выносить эту идею в philosophy/flame.comp не готов

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

_>Тут просто нехватка понятий. Обычно под ДСЛ понимают именно языковые конструкции, ключевые слова там новые и т.п.
Под ДСЛ, прежде всего, понимают его семантику.
Синтаксис штука приятная, но второстепенная.

_>В этом случае у нас от ДСЛ не так и много было — readlock, writelock, ещё что-то такое-же простое. А получилось что язык вообще стал отступать, под давлением всяких "неявных" реализаций. Это уже даже не DSL а Domain Specific Runtime что-ли.
Это вы просто начали менять семантику немерла так чтобы он начал подходить под ваши задачи.
Те это и есть настоящий ДСЛ.
Его конечно можно засыпать специализированным синтаксисом, но в вашем случае даст это не много.
Ибо синтаксис немерла вполне подходит к тому, что вы делаете.

Но это не всегда правда. Ибо, например, в случае с парсером синтаксис немерле не подходит и тут специализированный синтаксис уже рулит.

_>И чем дальше тем сильнее мы уходили от декларативного программирования, всё больше полагаясь на магию автогенерации, завязанную на совершенно нетрадиционные вещи — имена классов и namespace'ов, объявленные но не реализованные интерфейсы, тот же тип поля SyncRoot, значение константы Offset (там была магия с DateTime на разных системах).
Наоборот. Вы шли к декларативному программированию.
Ибо декларации задают логику.

_>Что было очень неожиданно, так как первое правило которое мы сами себе придумали — это что код не должен браться из ниоткуда. Типа там нам самим будет непонятно, если не будет аттрибута [AutoDispose] хотя-бы на классе, а лучше на мемберах. А оказалось наоборот, что аттрибуты тоже код, и если избавляться по-возможности и от них — то жить проще.
Именно.
Главное тут понять что происходит это за счет того что вы поменяли семантику немерла так что на него стало проще натягивать вашу предметную область.
Но все эти AutoDispose, ChangedBy итп это всё ещё фичи общего назначения.
Это хоть и существенные, но косметические фичи.

_>Да, и ещё интересный момент — связность кода за счёт иерархий наследования реализации стала сильно падать. Сейчас мне даже кажется что virtual и override это неправильный костыль, и можно выкатить язык на одних только интерфейсах и с макропрограммированием, и будет epic win. Но пока не потренируюсь на прототипе, выносить эту идею в philosophy/flame.comp не готов
Это опять рассуждения на уровне языка общего назначения.
Я не в курсе того что конкретно у вас делается но уверен что всю вашу логику можно переписать без всех этих readlock, writelock, AutoDispose итп.
Просто по тому, что это детали функционирования платформы и напрямую к бизнеслогике не относятся.
А значит если сделать чистый язык, который работает напрямую в терминах конкретной предметной области то можно все это сгенерировать.

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

F> Да ну? Древние это как? Есть реалии. C++11 — по факту, никем ещё не поддерживается, ближе всех gcc и clang, как я понимаю.
F> А вот написание — return Singleton<BuildInfo, LeakySingletonTraits<BuildInfo> >::get(); — суровая правда жизни.
А можно узнать, с чем мэтр C++ DarkEld3r — не согласен?
С тем, что >пробел> — это реальная правда жизни, и никуда от неё не дется в C++11?
С тем, что я так устарел, а у нас каждый компилятор поддерживает C++11 в полном объеме?
С чем конкретно? Расскажи уж. Просвяти всех. Я лично буду тока рад.

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

VD>Общая идея — макрос позволят добиться почти идеальной абстракции. Эта абстракция может выражать суть предметной области настолько точно насколько это только возможно, и при этом макрос позволяет сделать реализацию настолько конкретной и качественной насколько это нужно.

Важно только понимать, что макросы — не единственное средство, и уж тем более не факт, что лучшее.

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

VE>Важно только понимать, что макросы — не единственное средство, и уж тем более не факт, что лучшее.

Факт что лучшее. Но, конечно же не единственное.

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

VD>Факт что лучшее. Но, конечно же не единственное.

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

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

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

VE>>Важно только понимать, что макросы — не единственное средство, и уж тем более не факт, что лучшее.

VD>Факт что лучшее. Но, конечно же не единственное.

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

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

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

Можно поподробнее?

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

VE>Важно только понимать, что макросы — не единственное средство, и уж тем более не факт, что лучшее.
А что лучше макросов?

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

VE>>Важно только понимать, что макросы — не единственное средство, и уж тем более не факт, что лучшее.
WH>А что лучше макросов?

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

VE>Аноним вот написал про какие-то метасвязки, интересно бы узнать, что это такое.
VE>Я позволю себе сказать утрированно для краткости.
VE>Лучше макросов всё, что может быть использовано вместо них. Так что вопрос стоило бы поставить иначе "что хуже макросов", потому что хуже ничего нет, но иногда без них не обойтись. И вот это "иногда" надо изолировать и делать наименее необходимым за счёт улучшения основного языка.

+1. Метасвязки от Анонима — это, несомненно, будущее программирования.
Если бы он мог объяснить, то сказал примерно следующее:
компонентное программирование имеет очевидный недостаток — для скрепления компонентов нужно много рукописного, специфического кода.
если представить, что компоненты будут свойствами "автосвязи" и "авторасширения" с компонентами, которые находятся рядом, то мы можем
выйти на уровень роботов из жидкого металла, компоненты которых "знают" свое место и "знают" как реагировать со связными компонентами.

К стати, этим будущим мы ежедневно пользуемся. Понятия естественного языка — такие компоненты.

ЗЫ Так что верьте Анониму — дело говорит.

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

Ок. Спасибо. Пафос — то я не со зла.
Ну да, видимо кроссплатформенность, и долгое время ориентации на MSVC2008 и есть причина "суровой", а то что это ещё с gcc 4.3 пофикшено — не знал.

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

VD>Ага. Всегда проще наклеить ярлычок вроде "евангилизм", чем в чем-то разобраться и попробовать на практике.

До свидания.

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

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

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

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

_C_>>+1. Метасвязки от Анонима — это, несомненно, будущее программирования.
WH>Ты лучше ссылки на статьи дай.
WH>Ибо своими словами ты еще ни кому, ни чего, ни разу не объяснил.
Метасвязки не тьюринг подобное обобщение макросов. В общем случае скомпилировать программу написанную корректно в виде метасвязок за конечное время на машине тьюринга не возможно, так же как и исполнить.

Здравствуйте, <Аноним>, Вы писали:

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

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

I>До свидания.

Лучше — прощай.

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

Ты что-то путаешь. Евангелисты — это в Майрософт и т.п. Им за это деньги платят. Я всего лишь говорю, то что знаю сам.

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

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

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

VE>Неужели у тебя и доказательство имеется этого "факта"?
VE>Вопрос, конечно, риторический.

Риторические вопросы задавай где-нибудь в других местах. А то они больно на попытки разведение флэйма смахивают.

Ответ на твой вопрос был в том сообщении

Автор: VladD2
Дата: 10.07.12

на которое ты начал отвечать. Если ты действительно хочешь получить ответ на свой вопрос, перечитай это сообщение или сформулируй конкретные вопросы.

Еще можно вот это прочесть

Автор: VladD2
Дата: 13.07.12

.

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

VE>Аноним вот написал про какие-то метасвязки, интересно бы узнать, что это такое.
VE>Я позволю себе сказать утрированно для краткости.
VE>Лучше макросов всё, что может быть использовано вместо них. Так что вопрос стоило бы поставить иначе "что хуже макросов", потому что хуже ничего нет, но иногда без них не обойтись. И вот это "иногда" надо изолировать и делать наименее необходимым за счёт улучшения основного языка.

Это часто встречающееся заблуждение тех кто осваивает макросы. Сам через подобное прошел. Правда в том, что макросы дают нужный результат в 100% в то время когда традиционные методы абстракции функции и типы только иногда. Если бы не сложность реализации и отладки макросов, то можно было бы забыть о других методах.

А появляются подобные заблуждения из-за того, что макросы рассматриваются как подпорки для ЯОН (языка общего назнанчения), а не как средство разработки ДСЛ-ей.

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

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

VE>>Лучше макросов всё, что может быть использовано вместо них. Так что вопрос стоило бы поставить иначе "что хуже макросов", потому что хуже ничего нет, но иногда без них не обойтись. И вот это "иногда" надо изолировать и делать наименее необходимым за счёт улучшения основного языка.
WH>Макросы это и есть улучшение основного языка.

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

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

VD>Еще можно вот это прочесть

Автор: VladD2
Дата: 13.07.12

.

Что тут читать. Я бы мог вспомнить про правила перезаписи, или про то, что какая-нибудь Agda, имея на руках

proof : ∀{f g} → map f ∘ map g ≡ map (f ∘ g)

могла бы проводить оптимизации (те же правила перезаписи, только с док-вом корректности), но ты же это макросами сейчас обзовёшь.