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

IT>>Мнение всегда интересно. А выводы скорее нет, чем да.
AVK>Мнение это и есть выводы.

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

IT>>Ну и что?

AVK>Чем более базовый уровень подвергается изменениям, тем сложнее вхождение.

Базовый уровень не изменяется. Мы не меняем компилятор, мы его расширяем.

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

IT>> В том же шарпе 99% девелоперов не знают всех возможностей языка. Например, многие понятия не имеют что такое '??'. Так что мне теперь не использовать эти возможности?

AVK>Почему не использовать? Использовать. Знать язык в рнмках единого стандарта обязан каждый разработчик. А вот требовать с него изучения языка каждый раз, когда он сталкивается с новым набором макросов имхо перебор.

Не вижу никаких проблем. Ознакомление с новой системой всегда требует определённых усилий и ознакомление с макросами не будет ничем сверхестественным по сравнению с пониманием архитектуры приложения и ознакомлением с исходными кодами. Это будет уж точно не сложнее, чем понять формат используемых в приложении XML файлов, которые точно так же вводят в приложение новые конструкции, но при этом не проверяются компилятором.

IT>> Как ты правильно сказал, учить надо. И всё. Обучить вменяемого человека 10-ти макросам — это вообще не проблема.

AVK>А 20? А 100?

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

IT>>Интересно какими же ты макросами увлекался намного раньше?

AVK>Да были всякие разные типа Open C++. Но, как я предполагал, разговор скатывается во флейм.

Это не флейм. Это принципиальный вопрос. Одно дело, если ты с ними поигрался да и бросил. Другое — если ты использовал Open C++ в серьёзном проекте и твои утверждения о вреде макросов основываются не на домыслах, а на реальном опыте их применения.

AVK>А в том, что слишком много логики остается за кадром исходного кода.

Так это как раз и есть наша главная цель. Убрать частоповторяющуюся логику подальше, а в прикладном коде оставить максимум декларации. Почему тебя не пугает, например, что за вызовом метода Rsdn.Janus.Synchronizer.SyncForums остаётся много логики за кадром?

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

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

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

Я с этим не согласен. Тебя сильно интересует реализация паттернов foreach, override, yield return, this? Думаю не очень. Может быть ты лично и разобрался один раз как они работают. Но не думаю, что ты это делаешь каждый раз при их применении. А твоим обезъянкам так вообще по барабану.

AVK>>>Паттерн-матчинг в мейнстриме присутствует, но не в шарпе.
IT>>А где?
AVK>SQL например. Или XSLT.

А... ну да. Нам как раз здесь не хватает именно такого замеса.

IT>>Лямб пока нет. Есть убожество, называемое анонимными делегатами.
AVK>Во первых анонимными МЕТОДАМИ.

Начинается терминологический булшит? Анонимные МЕТОДЫ вводятся в коде ключевым словом delegate. Извините, если я неправильно выразился. Впрочем, я не одинок.

AVK>Во-вторых это те же лямбды, вид в профиль.

Если уж мы начали упираться в терминологию, то хочу обратить твоё внимание на тот факт, что термин Lambda Expressions вводится только в C# 3.0.

AVK>В-третьих, оставь подобные флеймогонные эпитеты.

Но ведь это же абсолютная правда

IT>>Думаю, ни тебе, ни Гапертону на PL/1 писать не приходилось.
AVK>Не угадал. Приходилось, хотя и в небольших объемах.

И как ощущение от пережитого? Что тебя большего всего угнетало: обилие фич или дремучесть вообще?

IT>>Теперь у кого-то точно также заклинивает башку и он в упор не видит преимуществ расширяемых компиляторов.
AVK>Я вот думаю, это Nemerle делает вас столь непримиримыми, или функциональное программирование вообще?

Это кто из нас здесь непримиримые? Я пишу и на C# и на Немерле и знаю их возможности не по наслышке. И я уж точно не буду говорить too big gun или что-то подобное о вещах, в которых не разбираюсь досконально.

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

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

IT>VM без разницы на каком языке был сгенертрован байт-код и с помощью каких расширений. Это как бы одна из основополагающих идей.

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

M>>IDE и VM были упомянуты не для перевода стрелок и отвлечения внимания. Они имеют непосредственное отношение к макросам, о чём я и написал достаточно подробно. Если вы этого не видите и не хотите видеть — так бы и сказали, мол обсуждать не хочу.

IT>Давай обсуждать, если очень хочется. Why not?
IT>По-моему мнению VM не имеет никакого отношения к расширению компилятора. Т.е. вообще никакого. Продукт компиляции — это байт-код. Как он был получен это не важно. Я генертрую байт код вручную с помошью emit'а без всякой компиляции. Тем не менее VM на меня за это вовсе не в обиде.

Этот процесс ничем не отличается от компиляции исходников OCaml в C. Они могут компилировать свои исходники в байткод для своей VM, а могут в исходный код на С.
Когда я говорю о расширении VM, то имеется в виду что-то вроде расширяемого байткода. Так же, как в Nemerle вы можете определять новые операторы, так и для такой расширяемой VM можно определять новые инструкции. Самый простой пример — определение SIMD операций, ты их можешь определить в Nemerle для работы с 3D вычислениями. Если это расширение компилятора — то эти операции должны будут скомпилироваться либо в вызовы библиотечных методов, либо развернуться в последовательность скалярных операций. Если это расширение VM, то эти операции будут скомпилированы либо в вызовы библиотечных методов, либо развёрнуты в последовательность скалярных операций, либо могут использоваться непосредственно аппаратные SIMD инструкции CPU.

M>>Скажем, у нас есть "расшитрение" для enum типов, и их использования в выражениях и switch/case. Для case value мы бы хотели в IDE иметь автодополнение, которое предлагало бы список перечислымых значений из декларации enum.

IT>Что такое "расширение" для enum типов? Это новый тип типов или новый enum?

Новый тип типов. Мне его удобно для примера пользовать, так как в Java изначально небыло enum-ов, и они реализуются сравнительно просто в виде "расширения", как трансформация AST (кодогенерация).

M>>Так вот, никаким образом этот тип автодополнения не появится автоматически из правил преобразования enum->class на уровне AST.
M>>IDE уровня Eclipse или IntelliJ Idea понимает код, работает с ним на уровне семантики. Поэтому и является настолько удобным инструментом. А вы под IDE подразумеваете редактор+обработчик сообщений компилятора?

IT>Я понимаю это как редактор + компилятор. Не секрет, что тот же Resharper включает в себя большую часть самописного компилятора C#. Фактически для IDE не нужна лишь последняя фаза кодогенерации. Остальное в ней присутствует в полный рост. Не думаю, что Idea и Eclipse в этом сильно отличаются. Что касается Немерле, то его интеграция с VS использует непосредственно сам компилятор. Соотвественно, если макрос, например, сгенертровал новый тип или метод в существующем типе, то он автоматически появится в списке интелисенс. Тоже самое касается новых ключевых слов.

Вот и смотрим, что произойдёт с гипотетическим расширением "enum типы". В Java это было сделано так

enum Color { red, green, blue }
...
int rgb(Color c) {
  switch (c) {
  case red: return 0xff;
  case green: return 0xff00;
  case blue: return 0xff0000;
  }
}

компилируется в

final class Color extends Enum {
  public static final red = new Color(0,"red");
  public static final green = new Color(1,"green");
  public static final blue = new Color(2,"blue");
  private Color(int ord, String name) { super(ord,name); }
  ...
}
...
int rgb(Color c) {
  switch (c.ordinal()) {
  case 0: return 0xff;
  case 1: return 0xff00;
  case 2: return 0xff0000;
  default: throw new Error();
  }
}

Теперь внимание — вопрос.
Каким образом из правил кодогенерации (трансформации AST) IDE сможет понять, что red, green, blue — это константы, что автодополнение кода в case value должно выдавать список из red,green,blue, каким образом IDE узнает, что существуют только 3 варианта значения Color и что switch может иметь максимум эти 3 case-а и так далее. Эти правила (что есть enum как понятие) — присутствуют в мозгах программиста. Трансформация AST — это применение этих правил, а не определение этих правил.

Idea и Eclipse построены именно на понимании явовского кода, а не его формальном AST представлении. Кроме самого AST туда ещё много чего напихано. Именно поэтом миграция на Java 1.5 (в которой эти enum-ы появились, а так-же generics, autoboxing и прочее) заняла пару лет для IDE, уже после того, как компилятор был выпущен.

IT>Пофантазировать можно конечно. MS research работает над проектом Феникс, возможно это из этой серии.

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

IT>>>Это неверное утверждение. Как я уже сказал, интеграция Немерле со студией автоматически подхватывает все расширения. Есть определённые технические проблемы, которые решаемы, но принципиальных проблем нет.

M>>Расскажите мне о решении принципиальной проблемы изложенной выше. Как будет происходить пониание кода средой разработки на основании одних только правил преобразования AST, не говоря уже о расширениях вроде изменения системы типов.

IT>Интеграция с VS использует сам компилятор. Т.е. исходный код проекта банально пропускается через компилятор и в результате IDE получает в своё распоряжение AST. В процессе компиляции выполняются в том числе и макросы. Соответственно, все сделанные ими изменения попадают в результирующее AST.

Как я написал выше, результирующее AST нам даёт очень мало, для понимания сути написанного. А если IDE не понимает сути написанного, то она превращается просто в редактор.

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

IT>>VM без разницы на каком языке был сгенертрован байт-код и с помощью каких расширений. Это как бы одна из основополагающих идей.

M>Между языком и VM тоже нет принципиальной разницы. Можешь рассматривать байткод как некий язык программирования со специфическим синтаксисом.

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

M>Этот процесс ничем не отличается от компиляции исходников OCaml в C. Они могут компилировать свои исходники в байткод для своей VM, а могут в исходный код на С.

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

M>Новый тип типов. Мне его удобно для примера пользовать, так как в Java изначально небыло enum-ов, и они реализуются сравнительно просто в виде "расширения", как трансформация AST (кодогенерация).

Понятно. Т.е. если я правильно понял, то enum в джаве представляет собой просто синтаксический сахар.

M>Теперь внимание — вопрос.
M>Каким образом из правил кодогенерации (трансформации AST) IDE сможет понять, что red, green, blue — это константы,

То что это константы следует из final. Правильно?

M>что автодополнение кода в case value должно выдавать список из red,green,blue, каким образом IDE узнает, что существуют только 3 варианта значения Color и что switch может иметь максимум эти 3 case-а и так далее.

В классе Color есть только эти три константы, соответственно показать мы можем только их.

M>Эти правила (что есть enum как понятие) — присутствуют в мозгах программиста. Трансформация AST — это применение этих правил, а не определение этих правил.

Для данного конкретного случая достаточно обучить IDE выдавать список констант определённых в классе. Вся информация для этого у нас есть в AST. То, что это именно enum знать совершенно не обязательно. В результате это будет работать не только для enum, а для любых вариантов данного паттерна.

M>Idea и Eclipse построены именно на понимании явовского кода, а не его формальном AST представлении.

И это очень плохо.

M>Кроме самого AST туда ещё много чего напихано. Именно поэтом миграция на Java 1.5 (в которой эти enum-ы появились, а так-же generics, autoboxing и прочее) заняла пару лет для IDE, уже после того, как компилятор был выпущен.

Не удивительно.

IT>>Пофантазировать можно конечно. MS research работает над проектом Феникс, возможно это из этой серии.

M>Приблизительно то-же говорят те, кто считает ненужным расширяемые компиляторы. Типа, "пофантазировать можно кончено". Вы их спрашиваете — как же они не видят полезности расширяемых компиляторов,

Нет, совсем не так. Они не просто не видят полезности, они яро протестуют. Большая разница.

M>а я так-же удивлён, почему ваша фантазия заканчивается на компиляторе.

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

IT>>Интеграция с VS использует сам компилятор. Т.е. исходный код проекта банально пропускается через компилятор и в результате IDE получает в своё распоряжение AST. В процессе компиляции выполняются в том числе и макросы. Соответственно, все сделанные ими изменения попадают в результирующее AST.

M>Как я написал выше, результирующее AST нам даёт очень мало, для понимания сути написанного. А если IDE не понимает сути написанного, то она превращается просто в редактор.

AST нам даёт всё что нужно. Возможно мы просто понимаем под AST разные вещи. Таже Idea наверняка производит некоторую трансляцию исходного кода в свои внутренние структуры. В Немерле исходный код преобразуется сначала в parsed tree, а затем в typed tree. Два этих дерева дают нам полную картину о структуре кода. Где, что, какие типы и т.п. Например, расположив курсор на ключевым словом while, которое является макросом, мы сможем наблюдать во что он раскрывается:

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

IT> Т.е. твой вывод, что макросы плохо, меня не интересует, а вот то почему ты так думаешь, очень даже интересно. Как мы это назовём? Аргументы? Доводы?

Не, аргументы это когда спорят. А спорить я не хочу.

AVK>>Чем более базовый уровень подвергается изменениям, тем сложнее вхождение.

IT>Базовый уровень не изменяется. Мы не меняем компилятор, мы его расширяем.

Расширение это тоже изменение. Не меняем, это когда мы действительно не меняем грамматику языка.

IT>Кстати, вопрос к тебе, на который Гапертон тоже не ответил. Ты отрицательно относишься только к макросам, которые вводят новый синтаксис, либо абсолютно ко всем?

Я крайне отрицательно отношусь к макросам, которые меняют синтаксис, и очень настороженно к макросам, которые пользуются синтаксисом существующим.

IT>Не вижу никаких проблем.

IT, еще раз — мне не интересно спорить. Поэтому мне все равно, что считаешь ты. Я высказываю свою точку зрения, ничего сверх того.

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

Я считаю иначе.

AVK>>А 20? А 100?

IT>Столько сколько нужно. Опять же, замечу ещё раз. За год работы на Немерле я не написал ни одного макроса.

Ничуть в том не сомневаюсь.

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

Потому что я вижу, что происходит с шаблонами на С++.

AVK>>Да были всякие разные типа Open C++. Но, как я предполагал, разговор скатывается во флейм.

IT>Это не флейм.

Это именно он и есть. И чем дальше, тем его больше.

IT>Это принципиальный вопрос. Одно дело, если ты с ними поигрался да и бросил. Другое — если ты использовал Open C++ в серьёзном проекте и твои утверждения о вреде макросов основываются не на домыслах, а на реальном опыте их применения.

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

AVK>>А в том, что слишком много логики остается за кадром исходного кода.

IT>Так это как раз и есть наша главная цель. Убрать частоповторяющуюся логику подальше,

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

IT> а в прикладном коде оставить максимум декларации. Почему тебя не пугает, например, что за вызовом метода Rsdn.Janus.Synchronizer.SyncForums остаётся много логики за кадром?

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

IT>Это не проблема.

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

IT>Тем не менее это ни меня, ни многих других не останавливает. Я точно знаю что я делаю и знаю какие бенефиты в результате получу.

Рад за тебя.

IT>Я с этим не согласен. Тебя сильно интересует реализация паттернов foreach, override, yield return, this?

Конечно.

IT>А твоим обезъянкам так вообще по барабану.

Нет, и обезьянкам не по барабану. Но foreach — часть языка, и обезьянка не имеет права не разбираться хотя бы в базовых моментах foreach. Грубо говоря, обезьянка будет изучать foreach за свой счет, чтобы потом устроится на работу в качестве C# developer.

AVK>>SQL например. Или XSLT.

IT>А... ну да. Нам как раз здесь не хватает именно такого замеса.

Тем не менее паттерн-матчинг в мейнстриме есть.

IT>>>Лямб пока нет. Есть убожество, называемое анонимными делегатами.
AVK>>Во первых анонимными МЕТОДАМИ.

IT>Начинается терминологический булшит?

Нет, просто поправил, уж больно глаза режет.

IT>Впрочем, я не одинок.

Уробы, чего на них равняться?

AVK>>Во-вторых это те же лямбды, вид в профиль.

IT>Если уж мы начали упираться в терминологию

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

IT>И как ощущение от пережитого? Что тебя большего всего угнетало: обилие фич или дремучесть вообще?

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

IT>>>Теперь у кого-то точно также заклинивает башку и он в упор не видит преимуществ расширяемых компиляторов.
AVK>>Я вот думаю, это Nemerle делает вас столь непримиримыми, или функциональное программирование вообще?

IT>Это кто из нас здесь непримиримые?

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

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

M>>Новый тип типов. Мне его удобно для примера пользовать, так как в Java изначально небыло enum-ов, и они реализуются сравнительно просто в виде "расширения", как трансформация AST (кодогенерация).

IT>Понятно. Т.е. если я правильно понял, то enum в джаве представляет собой просто синтаксический сахар.

Нет, записи "enum Color" и "class Color extends Enum" не эквивалентны. Синтаксический сахар — это упрощённый способ записи, а не определение нового семантического понятия.
Скажем, в Python записи "self.foo()" и "foo(self)" просто эквивалентны, потому accssor для call является синтаксическим сахаром — в нём нет семантики.

M>>Теперь внимание — вопрос.
M>>Каким образом из правил кодогенерации (трансформации AST) IDE сможет понять, что red, green, blue — это константы,

IT>То что это константы следует из final. Правильно?

final — это sealed, неизменяемая ссылка или значение. А константы в яве — это числа, символы и прочее. В switch можно было использовать только int/char, а теперь и enum (но не в перемешку с int!!!) — константность эта семантическая, а с точки зрения JVM они не являются константами.

enum-ы я привёл в качестве простого примера. Легко привести и более "продвинутые" примеры. Взять тот-же embedded SQL или GUI designer-ы.
В IDE, которая понимает SQL можно встроить дизайнер базы данных, auto-completition для embedded SQL.
В IDE, которая понимает GUI можно визуально строить диалоги, привязывать их к обработчикам событий и пр.
Наглядный пример — продукты Борланда. Дельфи и JBuilder имеют интегрированную поддержку SQL и GUI на уровне недоступном Nemerle как компилятору отдельному от IDE.
Аналогично MS Access и Visual Basic.
При этом дизайнер таблиц в Дельфи или Access — это полноценный язык программирования, только "визуальный", а не текстовый.

M>>Эти правила (что есть enum как понятие) — присутствуют в мозгах программиста. Трансформация AST — это применение этих правил, а не определение этих правил.

IT>Для данного конкретного случая достаточно обучить IDE выдавать список констант определённых в классе. Вся информация для этого у нас есть в AST. То, что это именно enum знать совершенно не обязательно. В результате это будет работать не только для enum, а для любых вариантов данного паттерна.

Вот именно. Надо обучить IDE. Обучим мы его конкретно enum-ам или целому классу подобных расширений — не суть важно. Я именно и говорю о необходимости обучения IDE тем расширениям, которые мы добавляем в компилятор. Тогда обученный IDE может интегрировать в единое целое и embedded SQL, и GUI designer, и редактировать комментарии в виде HTML/XML кода, и генерировать конфигурационные файлы (в формате XML, например) из настроек проекта и т.д. и т.п.

IT>Нет, совсем не так. Они не просто не видят полезности, они яро протестуют. Большая разница.

Они бы протестовали значительно меньше, если бы имели реальный опыт работы, и этот опыт показал полезность расширяемости компилятора. Плюс, эта полезность должна превышать потери. Возможно, их представления о потерях другие — для кого-то утрата GUI designer-а не представляет проблем, а для кого-то это ключевая фича инструмента. Полезность включает в себя много аспектов, вроде лёгкости освоения, типичных задач которые решал (и собирается решать) в своей жизни программист, качество поддержки и широта community и так далее.

IT>Меня в данном случае интересует именно компилятор. Все другие возможные на сегодняшний день способы автоматизации моей работы я уже прошёл и они мне действительно малоинтересны.

IT>AST нам даёт всё что нужно. Возможно мы просто понимаем под AST разные вещи.

Я не говорю о сегодняшнем дне, я говорю о завтрашнем.
Вы говорите о Nemerle, который работает только в рамках фиксированного набора AST узлов (и расширения компилятора строятся на композиции узлов) — это день сегодняшний.
А я говорю о расширяемом AST, где узел дополнительно описывает свою семантику, которая и служит как компилятору, так и IDE и VM, для работы с данным типом узлов — это день завтрашний.
Nemerle пытается остаться в рамках текстового представления, и тем ограничивает свою расширяемость и возможности интеграции расширений в другие средства разработки и исполнения программ. Его расширяемость даёт слишком небольшой результат, по сравнению с возникающими проблемами. В целом он лучше (хотя в частностях может уступать), чем тот-же C#, но эти преимущества не настолько велики, чтоб тратить огромные средства на переучивание массы народа, переписывания массы сопутствующих средств вроде IDE.

Мне кажется — это попытка перепрыгнуть пропасть в два прыжка. Если уже прыгнули в сторону расширяемости через трансформацию AST — то прыгать надо до конца, до полного использования AST на всех стадиях разработки программы. Заменить текст деревом. Конечно, так прыгать прийдётся дальше — зато больше шансов перепрыгнуть, а не потратить усилия впустую.

Возможность добавлять новые типы узлов, работать с семантическим деревом, а не синтаксическим — позволяет и полную интеграцию расширений в IDE, и возможность генерировать разный код для разных target платформ, и возможность использовать расширения в VM, проводить компиляцию с минимальными потерями семантики (и за счёт этого максимально оптимизировать исполнение программы) и многое другое. Компилятор сам по себе, новый язык программирования сам по себе — это слишком мало, слишком маленькая часть всех средств разработки и исполнения программ.

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

IT>>Базовый уровень не изменяется. Мы не меняем компилятор, мы его расширяем.
AVK>Расширение это тоже изменение. Не меняем, это когда мы действительно не меняем грамматику языка.

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

AVK>Я крайне отрицательно отношусь к макросам, которые меняют синтаксис, и очень настороженно к макросам, которые пользуются синтаксисом существующим.

Т.е. негативно к макросам вообще.

IT>>Не вижу никаких проблем.
AVK>IT, еще раз — мне не интересно спорить. Поэтому мне все равно, что считаешь ты. Я высказываю свою точку зрения, ничего сверх того.
AVK>Я считаю иначе.

AVK, мне все равно, что считаешь ты. Мне интересны мотивы. В общем, похоже это и есть основной лейтмотив нашей беседы. Пора завязывать.

IT>> Не нужно было. Почему вы считаете, что наличие макросов в языке приведёт к тотальному увлечению ими я не понимаю
AVK>Потому что я вижу, что происходит с шаблонами на С++.

В самих по себе шаблонах C++ нет ничего плохого. Проблема в том, что для метапрограммирования в C++ используются побочные эффекты компилятора. Как следствие, маловразумительный, запутанный код. Код макросов Немерле представляет собой самый обычный стандартный код. Никаких побочных эффектов компилятора не используется. Всё в пределах дизайна языка.

AVK>>>Да были всякие разные типа Open C++. Но, как я предполагал, разговор скатывается во флейм.
IT>>Это не флейм.
AVK>Это именно он и есть. И чем дальше, тем его больше.

Заметь. Я старательно убираю из дискуссии все места, где ты обвиняешь меня во флейме. Причём до сих пор делал это молча, надеясь на конструктив. Но со временем это начинает надоедать, особенно когда ты продолжаешь это делать и по странному стечению обстоятельств как раз в тех местах, где тебе либо нехочется отвечать, либо нечего сказать. Это неконструктивно.

IT>>Это принципиальный вопрос. Одно дело, если ты с ними поигрался да и бросил. Другое — если ты использовал Open C++ в серьёзном проекте и твои утверждения о вреде макросов основываются не на домыслах, а на реальном опыте их применения.

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

Да тут нечего мерять. Если бы у тебя был реальный опыт использования Open C++, то нашлись бы и ответы. А так только одни намёки на всезнание. В общем, всё ясно.

IT>>Так это как раз и есть наша главная цель. Убрать частоповторяющуюся логику подальше,

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

О любой цене никто не говорит. Я тебе ещё раз могу повторить. За год я не написал ни одного макроса. Ещё раз повторить?

IT>> а в прикладном коде оставить максимум декларации. Почему тебя не пугает, например, что за вызовом метода Rsdn.Janus.Synchronizer.SyncForums остаётся много логики за кадром?

AVK>Потому что эта логика жестко ограничивается контрактом, причем контрактом явным. Могут быть, конечно, побочные эффекты. Но в случае макросов и с контрактом неясно, и с побочными эффектами может быть все очень непросто.

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

IT>>Это не проблема.
AVK>Это реальная проблема, которую я почувствовал на своей шкуре, когда возился с кодогенерацией.

Т.е. получается что ты вообще против кодогенерации. Я правильно понимаю?

IT>>А твоим обезъянкам так вообще по барабану.
AVK>Нет, и обезьянкам не по барабану. Но foreach — часть языка, и обезьянка не имеет права не разбираться хотя бы в базовых моментах foreach. Грубо говоря, обезьянка будет изучать foreach за свой счет, чтобы потом устроится на работу в качестве C# developer.

Обезъянкам по барабану. Им скажут foreach будут писать foreach, скажут forall будут писать forall. Впрочем, обезъянки меня интересуют в последнюю очередь. Слава богу, пока с ними плотно работать приходилось не часто.

AVK>>>SQL например. Или XSLT.
IT>>А... ну да. Нам как раз здесь не хватает именно такого замеса.
AVK>Тем не менее паттерн-матчинг в мейнстриме есть.

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

IT>>Начинается терминологический булшит?
AVK>Нет, просто поправил, уж больно глаза режет.

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

IT>>И как ощущение от пережитого? Что тебя большего всего угнетало: обилие фич или дремучесть вообще?

AVK>Больше всего угнетало то, что крайне тяжело было читать чужой код, причем большей частью из-за обилия фич, которые мне неизвестны или известны плохо. Может, если бы я пописал на нем лет несколько, мне бы было все просто, но я столько не писал.

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

AVK>Ну а как еще расценивать? Сотню раз уже наверное повторил — не хочу с тобой спорить, а все равно гора агитации в ответ. Ты всерьез надеешься после того, как я не по одному разу выслушал все аргументы любителей N, все таки переубедить меня?

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

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

M>final — это sealed, неизменяемая ссылка или значение.

readonly в C#.

M>А константы в яве — это числа, символы и прочее. В switch можно было использовать только int/char, а теперь и enum (но не в перемешку с int!!!) — константность эта семантическая, а с точки зрения JVM они не являются константами.

Я ещё раз хочу подчеркнуть. Я предпочитаю отделять мух от котлет, а языкы от VM.

M>enum-ы я привёл в качестве простого примера. Легко привести и более "продвинутые" примеры. Взять тот-же embedded SQL или GUI designer-ы.

Это не имеет отношения к языку. Точнее, IDE может использовать некий интерфейс с языком для генерации кода (CodeDOM в VS), но прямого отношения к языку эти фичи IDE не имеют.

M>В IDE, которая понимает SQL можно встроить дизайнер базы данных, auto-completition для embedded SQL.
M>В IDE, которая понимает GUI можно визуально строить диалоги, привязывать их к обработчикам событий и пр.
M>Наглядный пример — продукты Борланда. Дельфи и JBuilder имеют интегрированную поддержку SQL и GUI на уровне недоступном Nemerle как компилятору отдельному от IDE.
M>Аналогично MS Access и Visual Basic.
M>При этом дизайнер таблиц в Дельфи или Access — это полноценный язык программирования, только "визуальный", а не текстовый.

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

M>Вот именно. Надо обучить IDE. Обучим мы его конкретно enum-ам или целому классу подобных расширений — не суть важно. Я именно и говорю о необходимости обучения IDE тем расширениям, которые мы добавляем в компилятор. Тогда обученный IDE может интегрировать в единое целое и embedded SQL, и GUI designer, и редактировать комментарии в виде HTML/XML кода, и генерировать конфигурационные файлы (в формате XML, например) из настроек проекта и т.д. и т.п.

Ну и что тут не так? IDE нужно обучать взаимодействию со всеми этими вещами. С этим я не спорю. В частности IDE нужно будет обучить понимать расширения конкретного языка. Что не так?

IT>>Нет, совсем не так. Они не просто не видят полезности, они яро протестуют. Большая разница.

M>Они бы протестовали значительно меньше, если бы имели реальный опыт работы, и этот опыт показал полезность расширяемости компилятора. Плюс, эта полезность должна превышать потери. Возможно, их представления о потерях другие — для кого-то утрата GUI designer-а не представляет проблем, а для кого-то это ключевая фича инструмента. Полезность включает в себя много аспектов, вроде лёгкости освоения, типичных задач которые решал (и собирается решать) в своей жизни программист, качество поддержки и широта community и так далее.

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

IT>>AST нам даёт всё что нужно. Возможно мы просто понимаем под AST разные вещи.
M>Я не говорю о сегодняшнем дне, я говорю о завтрашнем.

Ну так с этого нужно было и начинать

M>Вы говорите о Nemerle, который работает только в рамках фиксированного набора AST узлов (и расширения компилятора строятся на композиции узлов) — это день сегодняшний.
M>А я говорю о расширяемом AST, где узел дополнительно описывает свою семантику, которая и служит как компилятору, так и IDE и VM, для работы с данным типом узлов — это день завтрашний.

Пока что это фантазии. Я бы даже сказал фантазёрство.

M>Мне кажется — это попытка перепрыгнуть пропасть в два прыжка.

Да хоть в три. Главное, что другая сторона отчётливо видна. То, о чём говоришь ты — это прыжок в туман, за которым может оказаться пустота.

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

AVK>>Я крайне отрицательно отношусь к макросам, которые меняют синтаксис, и очень настороженно к макросам, которые пользуются синтаксисом существующим.

IT>Т.е. негативно к макросам вообще.

Я сказал то что сказал, не надо меня перефразировать.

AVK>>IT, еще раз — мне не интересно спорить. Поэтому мне все равно, что считаешь ты. Я высказываю свою точку зрения, ничего сверх того.
AVK>>Я считаю иначе.

IT>AVK, мне все равно, что считаешь ты.

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

AVK>>Потому что я вижу, что происходит с шаблонами на С++.

IT>В самих по себе шаблонах C++ нет ничего плохого. Проблема в том, что для метапрограммирования в C++ используются побочные эффекты компилятора. Как следствие, маловразумительный, запутанный код.

А мне кажется, что сама идея кодогенерации тоже играет немаловажную роль.

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

Ты мне это для чего говоришь? Мне все равно чего там в Nemerle, абсолютно.

IT>Заметь. Я старательно убираю из дискуссии все места, где ты обвиняешь меня во флейме. Причём до сих пор делал это молча, надеясь на конструктив. Но со временем это начинает надоедать, особенно когда ты продолжаешь это делать и по странному стечению обстоятельств как раз в тех местах, где тебе либо нехочется отвечать, либо нечего сказать. Это неконструктивно.

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

IT>В общем, всё ясно.

Мне тоже. Увы, мои предсказания сбылись на 100%, несмотря на массу усилий избежать этого.

IT>О любой цене никто не говорит. Я тебе ещё раз могу повторить. За год я не написал ни одного макроса. Ещё раз повторить?

А зачем ты мне это повторяешь?

AVK>>Потому что эта логика жестко ограничивается контрактом, причем контрактом явным. Могут быть, конечно, побочные эффекты. Но в случае макросов и с контрактом неясно, и с побочными эффектами может быть все очень непросто.

IT>Что именно может быть не просто? Только, пожалуйста, без общих фраз типа базовый уровень и грамматика языка. Лучше всего конкретный пример.

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

IT>Т.е. получается что ты вообще против кодогенерации. Я правильно понимаю?

Против кодогенерации как базовой возможности языка.

IT>Я даже не знаю что сказать. Аргумент, конечно, железный, на и настолько же бестолковый.

Аргумента нет.

IT>Зачем мешать всё в одну кучу? Только для того, чтобы... блин, без мата не могу даже фразу построить... о... чтобы додолбаться до слов оппонента?

Оппонент может быть только в споре. Я с тобой принципиально спорить не хочу.

IT>Ну тогда и я тебя поправлю. В спецификации языка это называется анонимными функциями.

У тебя какая то странная спецификация.
C# Version 2.0 Specification, July 2005, page 6

19.2 Anonymous methods

IT>Короче, всё ясно.

Мне тоже.

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

AVK>У тебя какая то странная спецификация.
AVK>C# Version 2.0 Specification, July 2005, page 6
AVK>

19.2 Anonymous methods

А, ну да, точно. Анонимный метод это:

delegate (int x) { return x + 1; }

а анонимная функция это:

x => x + 1

А что же тогда такое лямбда? Ты же говорил что это одна хрень.

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


IT>О любой цене никто не говорит. Я тебе ещё раз могу повторить. За год я не написал ни одного макроса. Ещё раз повторить?

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

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

IT>>О любой цене никто не говорит. Я тебе ещё раз могу повторить. За год я не написал ни одного макроса. Ещё раз повторить?

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

Нет, это совсем другая мысль. Макросы мне не нужны для тех задач, которые я в данный момент решаю, потому что для этих задач всё что нужно уже есть. Будут новые задачи, будет новый необходимый набор решений. Но макросов на каждый чих (чего больше всего боятся мои оппоненты) не будет. Именно эту мысль я озвучил.

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

IT>Макросы мне не нужны для тех задач, которые я в данный момент решаю, потому что для этих задач всё что нужно уже есть. Будут новые задачи, будет новый необходимый набор решений. Но макросов на каждый чих (чего больше всего боятся мои оппоненты) не будет. Именно эту мысль я озвучил.

Будет новый набор решений, но вот обязательны ли для них макросы?
Имхо, нужно ограничить их реализумость/применимость/видимость. Т.е. сделать что-то аля "только программист с чёрным поясом по N может писать макросы и он должен учитывать по возможности последствия их применения".

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

AVK>Нет, и обезьянкам не по барабану. Но foreach — часть языка, и обезьянка не имеет права не разбираться хотя бы в базовых моментах foreach. Грубо говоря, обезьянка будет изучать foreach за свой счет, чтобы потом устроится на работу в качестве C# developer.

Выделенное утверждение просто супер!
Зная этот базовый набор можно изучить любую библиотеку.
В случае макросов обезьянка не может их изучить за свой счёт. Следовательно издержки растут.
Я правильно понимаю твою позицию?

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

IT>Т.е. получается, что изменение грамматики плохо, потому что мы меняем базовый уровень. А базовый уровень плохо, потому что мы меняем грамматику языка. Понял.

Я правильно понимаю, что для того, чтобы понять что делает макрос нужно довольно подробно представлять как устроено AST,
какие есть фазы компиляции, как AST может трансформироваться на каждой из них?
Т.е. при применении макроса с моим кодом может произойти практически любая трансформация?
Если так, то именно это людей и настораживает.
Потому как я применяя yield return точно знаю, что сделает компилятор и как это всё локализовано.

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

EC>Я правильно понимаю, что для того, чтобы понять что делает макрос нужно довольно подробно представлять как устроено AST,
EC>какие есть фазы компиляции, как AST может трансформироваться на каждой из них?
EC>Т.е. при применении макроса с моим кодом может произойти практически любая трансформация?
EC>Если так, то именно это людей и настораживает.
EC>Потому как я применяя yield return точно знаю, что сделает компилятор и как это всё локализовано.

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

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

EC>>Я правильно понимаю, что для того, чтобы понять что делает макрос нужно довольно подробно представлять как устроено AST,
EC>>какие есть фазы компиляции, как AST может трансформироваться на каждой из них?
EC>>Т.е. при применении макроса с моим кодом может произойти практически любая трансформация?
EC>>Если так, то именно это людей и настораживает.
EC>>Потому как я применяя yield return точно знаю, что сделает компилятор и как это всё локализовано.

M>Свобода действий устрицы ограничена двумя состояними — открытой или закрытой раковиной. Именно это деалет поведение устриц столь понятным и надёжным. Увы, пока эти значительные преимущества не превратились в доминирование устриц как биологического вида, но природа работает над этим.

Расшифровываю свою мысль специально для юмористов: макросы повышают порог вхождения -> увеличивают стоимость разработки.
Если для более традиционных способов написания кода есть куча техник и практик, то с макросами всё не так радужно.
На данный момент это больше похоже на чёрную магию.
Безусловно, что в прямых руках и при наличии адекватной задачи это может быть лучшее средство.

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

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

EC>Расшифровываю свою мысль специально для юмористов: макросы повышают порог вхождения -> увеличивают стоимость разработки.
EC>Если для более традиционных способов написания кода есть куча техник и практик, то с макросами всё не так радужно.
EC>На данный момент это больше похоже на чёрную магию.
EC>Безусловно, что в прямых руках и при наличии адекватной задачи это может быть лучшее средство.

Расшифровываю свою мысль специально для вас.
Да, макросы увеличивают сложность компилятора и непредсказуемость его поведения при внесении изменения в код макроса или даже просто код программы.
Но при этом часто встречается ситуация, когда усложнение освоения и отладки компилятора на, скажем, 10% (то есть тратится дополнительное время на изучение, на отладку, на постоянно возникающие проблемы взаимного влияния этого макроса и остального кода), а упрощение кода (от использования этого макроса) составит 1000%. И чем более сложный проект мы пишем — тем более вероятна ситуация, когда бонусы от конкретного макроса значительно превысят проблемы возникающие от него-же.

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

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

M>Расшифровываю свою мысль специально для вас.

Расшифровка поскипана т.к. это понятно и без неё.
Можете привести какие-то из задач, которые вы решаете где макросы самое оно?

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

EC>Можете привести какие-то из задач, которые вы решаете где макросы самое оно?

Чем сложнее программа, тем проще привести пример.
Вот я пишу компилятор (http://www.symade.org), я использую дерево узлов. Это дерево поддерживает версионность (одновременное существование нескольких версий дерева, возможность откатить изменения и т.д.), у него есть constraints (вроде того, что узел может иметь только одного родителя), мне нужен механизм интроспектирования дерева (вроде reflection — какие узлы обладают какими аттрибутами) и многое другое. Я написал систему трансформации AST, которая мне генерирует все необходимые дополнительные классы и методы. Объём сгенерированного кода в разы превышает объём вручную написанного кода, модификация алгоритмов (версионности, интроспекции) практически не требует изменения кода и так далее. Без этой системы генерации кода потребовалось бы раз в 100 больше man-month, я один этот код в принципе не смог бы написать и продолжать развивать. Объём "генератора" всего около 1000 строк, и объём дополнительного низкоуровневого кода (базовых классов) лишь около 2000 строк.

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

EC>Зная этот базовый набор можно изучить любую библиотеку.

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