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

E>>Только ведь и отнюдь не минималистические подходы C++ и Java работают. И очень даже не плохо.

IT>Работают, но хреново?

См. выделенное.

Статья, безусловно, интересная. Хотелось бы только отметить, что за кадром остался анализ практических последствий полной синтаксической свободы. Легкость восприятия не менее важна чем легкость программирования. Да, Nemerle позволяет писать писать более понятный и читаемый код чем C++. Но позволяет и совершенно обратное. Конечно, и на С++ можно написать код понятный только автору (а то и вообще только вселенскому разуму), но строгий синтаксис все-таки затрудняет подобные действия. А теперь представьте, что Nemerle стал сравним по популярности с C++ или С#. Какой процент реальных программистов будет использовать возможность расширения синтаксиса во вред, а какой во благо? Хотя, возможно, это тема для отдельной статьи. В заключение цитата с MSDN:


здесь

The C# IDE (February 23, 2006)


Chat Topic: The C# IDE — part of Visual Studio
Date: Thursday, February 23, 2006


Cyrusn_MS (Expert):
Q: since we're on the subject of from/where/select...it would be a *huge* win if you could provide a general mechanism for those kinds of syntax transformations in C#. nemerle has a nice simple way to do it, and it'd be great to see something like that
A: Wolf: It's definitely been considered (and argued passionately for) but for 3.0 we are thinking that that would be too much flexibility to expose to our huge user base. The main issue would be that you would now have something akin to the C++ world today where when you go to any company (or heck, any team) you see code that doesn't look *anything* like any other code you've ever seen. People will be writing specific macros for everything, and there will no longer be things that you can identify as "C#"

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

E>>>Только ведь и отнюдь не минималистические подходы C++ и Java работают. И очень даже не плохо.

IT>>Работают, но хреново?

E>См. выделенное.

Ты там ИМХО забыл добавить.

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

E>>>>Только ведь и отнюдь не минималистические подходы C++ и Java работают. И очень даже не плохо.

IT>>>Работают, но хреново?

E>>См. выделенное.

IT>Ты там ИМХО забыл добавить.

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

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

E>Хотя, возможно, это тема для отдельной статьи.

Возможно. Если она не бедет основана на домыслах, предположениях и аналогиях из С++ (у которого проблемы арстут совсем из другого места), а напротив, она будет являться обобщением опыта языков которые уже давно имеют в своем арсенале подобные мощьные средства (это в первую очередь Лисп, Схема, Caml4p, Мета Хаскель и т.п.), естественно с учетом особенностей Nemerle, то я бы и сам с огромным удовольствием почитал бы такую статью.

Ну, а потка и отвечать не на что. IMHO проитв IMHO особой ценности не имеет.

E>Cyrusn_MS (Expert):
E>Q: since we're on the subject of from/where/select...it would be a *huge* win if you could provide a general mechanism for those kinds of syntax transformations in C#. nemerle has a nice simple way to do it, and it'd be great to see something like that
E>A: Wolf: It's definitely been considered (and argued passionately for) but for 3.0 we are thinking that that would be too much flexibility to expose to our huge user base. The main issue would be that you would now have something akin to the C++ world today where when you go to any company (or heck, any team) you see code that doesn't look *anything* like any other code you've ever seen. People will be writing specific macros for everything, and there will no longer be things that you can identify as "C#"
E>[/q]

Отмазка она и есть отмазка. Но одно то, что ребята задумались над этим уже вселяет надежду.

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

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

Спасибо за статью.

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

Вы очень хорошо и красиво говорили о Nemerle, и у меня только один вопрос. Какая конструкция выглядит проще и красивее:

foreach (i in [0 .. 100])
  // делаем что-то с i

while (iterator.MoveNext())
{
  // делаем что-то с iterator
}

И точно так же все это можно выражать через хвостовую рекурсию (код на Nemerle):

def Loop1(iterator, accumulator)
{
  if (iterator.MoveNext())
    // делаем что-то с iterator и accumulator
    Loop1(iterator, accumulator); // возвращаем значение рекурсивного вызова
  else
    accumulator // возвращаем значение аккумулятора
}

def Loop2(i, accumulator)
{
  if (i < 100)
    // делаем что-то с i и accumulator
    Loop(i + 1, accumulator);
  else
    accumulator 
}

// Запускаем «циклы».
Loop1(iterator, xxx);
Loop2(0, yyy);

На мой взгляд, язык программирования должен быть в первую очередь понятным и иметь простой синтаксис (чтобы не опуститься, или наоборот подняться(?) до уровня, например, Perl, который в шутку называют Write-Only языком), ибо там где много сложностей (не важно, во имя чего они создавались) легче нагромоздить ошибок.
Я согласен, "хвостовая рекурсия" звучит прекрасно. Но ведь помимо удобства, есть еще и стоимостные затраты на обучение и сопровождение, не так ли? Код, написанный на языке с простым и понятным синтаксисом, гораздо проще поддерживать и сопровождать, как мне кажется.

Ваша статья лично для меня прозвучала как ода Nemerle. Разве у этого языка нет недостатков? Совсем нет? Он совершенен? Идеален? Мне кажется, с этой точки зрения ваша статья получилась немного однобокой. Итог вы подводите одной фразой:

А пока что хочется подытожить. C++ проигрывает это сравнение молодому языку Nemerle.

Кстати, а как в Memerle обстоит дело со скоростью исполнения скомпилированного кода?

В C++ нет средств расширения синтаксиса!

Ну, наверное, перегрузку операторов нельзя считать расширением синтаксиса, так что тут вы правы. Но с другой стороны, разве хорошо иметь язык, синтаксис которого можно расширять в самом языке? То есть, фактически язык можно сделать таким, каким ты хочешь его видеть, так? Захотел, назвал операцию while — "while", а захотел — "cyclew", правильно? Как вы считаете, хорошо ли давать подобную свободу программисту? Да, это действительно удобно. Это действительно похоже на некое "метапрограммирование". Но хорошо ли это для качества кода? Для командной разработки программных продуктов? Сколько страниц будут занимать правила написания кода программы для какого-либо проекта в сравнении с аналогичными для, скажем, C#? Насколько возрастут затраты на написание подобного документа и насколько просто будет потом другим пользователям (если это, например, opensource проект) разбираться в написанном коде не прочитав этот талмуд.

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

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

FR>Вы очень хорошо и красиво говорили о Nemerle, и у меня только один вопрос. Какая конструкция выглядит проще и красивее:
Ты видимо плохо статью прочитал.

FR>На мой взгляд, язык программирования должен быть в первую очередь понятным и иметь простой синтаксис (чтобы не опуститься, или наоборот подняться(?) до уровня, например, Perl, который в шутку называют Write-Only языком), ибо там где много сложностей (не важно, во имя чего они создавались) легче нагромоздить ошибок.
С этим никто не спорит. И тут у Nemerle проблем нет.

FR>Я согласен, "хвостовая рекурсия" звучит прекрасно. Но ведь помимо удобства, есть еще и стоимостные затраты на обучение и сопровождение, не так ли? Код, написанный на языке с простым и понятным синтаксисом, гораздо проще поддерживать и сопровождать, как мне кажется.
Там же ясно написано:

Однако в определенных случаях некоторые конструкции более выразительны. Иногда самым выразительным циклом является while. Иногда – foreach. А иногда – хвостовая рекурсия (например, в алгоритмах обхода дерева).

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

FR>Ваша статья лично для меня прозвучала как ода Nemerle. Разве у этого языка нет недостатков? Совсем нет? Он совершенен? Идеален?
Это один из лучших языков на данный момент.

FR>Кстати, а как в Memerle обстоит дело со скоростью исполнения скомпилированного кода?
Nemerle компилируется в MSIL плюс есть некоторые оптимизации во фронтенде за счет которых он иногда работает быстрее чем C# те скорость болие чем приличная.

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

using MyMacroNamespace;

или по полному имени

MyMacroNamespace.MyMacro(...);

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

FR>То есть, фактически язык можно сделать таким, каким ты хочешь его видеть, так? Захотел, назвал операцию while — "while", а захотел — "cyclew", правильно?
Ну если мозгов нет то да.

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

FR>Да, это действительно удобно. Это действительно похоже на некое "метапрограммирование".
Это не похоже на метапрограммирование. Это оно во всей красе и есть.

FR>Но хорошо ли это для качества кода?
Если мозги есть то да. Если нет то ничего не поможет и уж точно без мозгов нельзя брать в руки С++ ибо это очень опасный язык.

FR>Для командной разработки программных продуктов? Сколько страниц будут занимать правила написания кода программы для какого-либо проекта в сравнении с аналогичными для, скажем, C#? Насколько возрастут затраты на написание подобного документа и насколько просто будет потом другим пользователям (если это, например, opensource проект) разбираться в написанном коде не прочитав этот талмуд.
Ну примерно на строчку:

Макросы писать нельзя.

Или

Макросы может писать только старший программист или доверенный человек.

А в сильной комманде и этого не понадобится.

Спасибо. Ваш пост можно свести к одному — у FractalizeR нет мозгов.
Благодарю.

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

FR>Спасибо. Ваш пост можно свести к одному — у FractalizeR нет мозгов.
FR>Благодарю.

Не надо расстраиваться. WolfHound парень немного резкий, но хороший. Просто молодой ещё

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

FR>Спасибо за статью.
+1

FR>Честно говоря, я даже о языке таком не слышал и ваша статья стала для меня поводом залезть в интернет покопать

Оооо. Почаще заходите в форум "Философия программирования". Столько нового узнаете

FR>Вы очень хорошо и красиво говорили о Nemerle, и у меня только один вопрос. Какая конструкция выглядит проще и красивее:

Насколько я понял из статьи и многочисленных постов ее автора, та конструкция "выглядит проще и красивее", которая употреблена к месту. И я того же мнения (с)

FR>На мой взгляд, язык программирования должен быть в первую очередь понятным и иметь простой синтаксис (чтобы не опуститься, или наоборот подняться(?) до уровня, например, Perl, который в шутку называют Write-Only языком), ибо там где много сложностей (не важно, во имя чего они создавались) легче нагромоздить ошибок.

А че вы! Перл классный язык
А если серъезно, то код на Немерле читается не многим сложнее кода на C#. Привыкание приходит быстро. Да и сложностей там особых нет. Так что ваши опасения беспочвены.

FR>Я согласен, "хвостовая рекурсия" звучит прекрасно. Но ведь помимо удобства, есть еще и стоимостные затраты на обучение и сопровождение, не так ли? Код, написанный на языке с простым и понятным синтаксисом, гораздо проще поддерживать и сопровождать, как мне кажется.

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

FR>Ваша статья лично для меня прозвучала как ода Nemerle. Разве у этого языка нет недостатков? Совсем нет? Он совершенен? Идеален?

Ага, щас, размечтались

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

А пока что хочется подытожить. C++ проигрывает это сравнение молодому языку Nemerle.

Да C++ многим языкам на самом деле проигрывает. А с другой стороны у многих выигрывает. Смотря по каким параметрам сравнивать. Для сравнения приводимого в статье, итог вполне закономерный.

FR>Кстати, а как в Memerle обстоит дело со скоростью исполнения скомпилированного кода?

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

FR>

В C++ нет средств расширения синтаксиса!

FR>Ну, наверное, перегрузку операторов нельзя считать расширением синтаксиса, так что тут вы правы.

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

FR>Но с другой стороны, разве хорошо иметь язык, синтаксис которого можно расширять в самом языке?

Иметь такую возможность безусловно хорошо.

FR>То есть, фактически язык можно сделать таким, каким ты хочешь его видеть, так? Захотел, назвал операцию while — "while", а захотел — "cyclew", правильно?

Правильно.

FR>Как вы считаете, хорошо ли давать подобную свободу программисту?

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

FR>Да, это действительно удобно. Это действительно похоже на некое "метапрограммирование".

Похоже? Да это оно самое!

FR>Но хорошо ли это для качества кода? Для командной разработки программных продуктов? Сколько страниц будут занимать правила написания кода программы для какого-либо проекта в сравнении с аналогичными для, скажем, C#? Насколько возрастут затраты на написание подобного документа и насколько просто будет потом другим пользователям (если это, например, opensource проект) разбираться в написанном коде не прочитав этот талмуд.

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

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

FR>Какая конструкция выглядит проще и красивее:

FR>

foreach (i in [0 .. 100])
FR>  // делаем что-то с i

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

FR>На мой взгляд, язык программирования должен быть в первую очередь понятным и иметь простой синтаксис (чтобы не опуститься, или наоборот подняться(?) до уровня, например, Perl, который в шутку называют Write-Only языком), ибо там где много сложностей (не важно, во имя чего они создавались) легче нагромоздить ошибок.

Совершенно верно. Я вот, например, немного пописав на N стал ловить себя на мысле, что return совершенно лишний элемент синтаксиса в C#. Точнее в самом C# этот элемент, конечно же необходим, но мне он стал мешаться под ногами. Ещё в C# постоянно напрягает громоздкость анонимных делегатов. В принципе, боюсь, что именно это является некоторым тормозом их более широкого распространения. Ещё можно было бы упростить switch, выкинув оттуда break как обязательный, но совершенно лишний элемент. Вывод типов — ещё один пример того, как можно упростить синтаксис и сделать язык более понятным. И т.д.

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

FR>Я согласен, "хвостовая рекурсия" звучит прекрасно. Но ведь помимо удобства, есть еще и стоимостные затраты на обучение и сопровождение, не так ли? Код, написанный на языке с простым и понятным синтаксисом, гораздо проще поддерживать и сопровождать, как мне кажется.

Думаю, что затраты на обучение C# программиста работе на Nemerle будут несоизмеримо далеки от затрат на переход с C на C++, с DOS на Windows, переход на COM или с Win32 на .NET.

FR>Ваша статья лично для меня прозвучала как ода Nemerle. Разве у этого языка нет недостатков? Совсем нет? Он совершенен? Идеален? Мне кажется, с этой точки зрения ваша статья получилась немного однобокой. Итог вы подводите одной фразой:

FR>

А пока что хочется подытожить. C++ проигрывает это сравнение молодому языку Nemerle.

Проигрывает. C++ проигрывает в простоте C# и джаве. А тот же C# приобретёт некоторые возможности Nemerle только в следующей версии. Да и то в несколько урезанном виде.

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

FR>Кстати, а как в Memerle обстоит дело со скоростью исполнения скомпилированного кода?

С этм всё в порядке.

FR>Ну, наверное, перегрузку операторов нельзя считать расширением синтаксиса, так что тут вы правы. Но с другой стороны, разве хорошо иметь язык, синтаксис которого можно расширять в самом языке? То есть, фактически язык можно сделать таким, каким ты хочешь его видеть, так? Захотел, назвал операцию while — "while", а захотел — "cyclew", правильно? Как вы считаете, хорошо ли давать подобную свободу программисту? Да, это действительно удобно. Это действительно похоже на некое "метапрограммирование". Но хорошо ли это для качества кода? Для командной разработки программных продуктов?

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

FR>Сколько страниц будут занимать правила написания кода программы для какого-либо проекта в сравнении с аналогичными для, скажем, C#? Насколько возрастут затраты на написание подобного документа и насколько просто будет потом другим пользователям (если это, например, opensource проект) разбираться в написанном коде не прочитав этот талмуд.

А сколько на это обычно уходит времени?

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

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

FR>Вы очень хорошо и красиво говорили о Nemerle, и у меня только один вопрос. Какая конструкция выглядит проще и красивее:
FR>На мой взгляд, язык программирования должен быть в первую очередь понятным и иметь простой синтаксис
Ты не понял. И пример с while, и пример с foreach это тоже Nemerle. Мне кажется VladD2 вовсе не пропагандировал использования рекурсивных функции вместо циклов. Он лишь хотел продемонстрировать подход Nemerle, заключающийся в фактическом отсутствии циклов в языке. Циклы while, for, foreach там как раз и сводятся в конечном итоге к локальной функции с хвостовой рекурсией, но внешне выглядят вполне привычно для императивного программиста.

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

Императивный подход(циклы, переменные, возвраты, ветвления):

    public Contains(element : T) : bool
    {
        mutable subTree = this;
        while(!(subTree is Nil))
        {
            def node = subTree :> Node;
            def c = element.CompareTo(node.element);
            if (c == 0)
            {
                return true;
            }
            else if (c <= -1)
            {
                subTree = node.left;
            }
            else
            {
                subTree = node.right;
            }
        }
        return false;
    }

Функциональный подход(паттерн-мэтчинг, рекурсия, правда в данному случае не хвостовая):

    public Contains(element : T) : bool
    {
        match(this)
        {
            | Nil => false
            | Node(left, el, right) =>
                match(element.CompareTo(el))
                {     
                    | 0 => true
                    | c when (c <= -1) => left.Contains(element)
                    | _  => right.Contains(element)
                }
        }
    }

FR>На мой взгляд, язык программирования должен быть в первую очередь понятным и иметь простой синтаксис
Разработчики Nemerle твою точку зрения разделяют. Именно поэтому Nemerle и был создан. Авторам Nemerle нравился язык ML, но они хотели создать что-то похожее по возможностям, но имеющее более понятный и близкий для большинства программистов синтаксис(предполагаю что и для них самих, так как их компиляторы изначально разрабатывались на ML, а затем переписывались на себе), а именно синтаксис напоминающий C. Так появился первый прототип Nemerle, язык Gont(с придумыванием хороших названий у главного автора Nemerle явно проблемы ). Затем было принято решение разрабатывать язык для платформы .NET, так как это дало бы доступ к обширной стандартной библиотеке. Заодно язык стал объектно-ориентированным и стал больше похож по семантике и синтаксису на C#. Кроме того, что язык гораздо ближе к традиционным языкам, чем диалекты ML, в первую очередь системой типов и синтаксисом, он еще и прекрасно интегрируется с другими языками .NET, а для языка хорошо поддерживающего парадигмы и возможности свойственные ML, это ценное и редкое качество(F#, разрабатываемый Microsoft и рядом не валялся).

FR>(чтобы не опуститься, или наоборот подняться(?) до уровня, например, Perl, который в шутку называют Write-Only языком), ибо там где много сложностей (не важно, во имя чего они создавались) легче нагромоздить ошибок.
Сравнение с Perl совершенно не уместно. Как раз с Perl у Nemerle крайне мало схожего, как в плане синтаксиса, так и семантики.

FR>Я согласен, "хвостовая рекурсия" звучит прекрасно. Но ведь помимо удобства, есть еще и стоимостные затраты на обучение и сопровождение, не так ли?
Как раз поэтому Nemerle делает все, чтобы эти затраты были как можно ниже. Во-первых первоначальное обучение Nemerle не более затратно, чем обучение C#(и человек, знающий C#, практически уже знает и основы Nemerle). О затратах на сопровождение судить не берусь, но по тому насколько успешно люди, которые казалось бы совсем недавно только услышали о Nemerle, уже участвуют в проекте, вносят изменения в компилятор(а он написан на Nemerle) и используют его внутренности, можно предположить, что они совсем не будут велики.

FR>Код, написанный на языке с простым и понятным синтаксисом, гораздо проще поддерживать и сопровождать, как мне кажется.
Совершенно верно. Nemerle как раз и является таким языком.

FR>Ваша статья лично для меня прозвучала как ода Nemerle. Разве у этого языка нет недостатков? Совсем нет? Он совершенен? Идеален?
Не идеален. Некоторые вещи меня например раздражают с самого начала знакомства с языком и до сих пор(хотя я с пониманием отношусь к мотивам авторов языка, которые привели к таким решениям дизайна, но все равно не разделяю их точку зрения до конца). Но, по ряду субъективных критериев, лучшего инструмента на данный момент не существует. Если конечно не пойти на ряд компромиссов(смириться с избыточными скобками и прочей несуразицей Лиспа) или отказаться от ряда вещей(вроде ООП, статической типизации, макросов или чего-нибудь другого).

FR>Кстати, а как в Memerle обстоит дело со скоростью исполнения скомпилированного кода?
Примерно также как и у C#. Иногда чуть лучше, иногда чуть хуже.

FR>

В C++ нет средств расширения синтаксиса!

FR>Ну, наверное, перегрузку операторов нельзя считать расширением синтаксиса, так что тут вы правы.
Не наверное, а точно. Перегрузка операторов это расширение семантики.

FR>Но с другой стороны, разве хорошо иметь язык, синтаксис которого можно расширять в самом языке?
Плохо иметь язык, который можно расширить на лексическом уровне. Причем расширить крайне деструктивно и при этом не извлечь практически никакой пользы от такого "расширения". Таким языком как раз является C++(это я о его "замечательном" встроенном препроцессоре если что).

FR>То есть, фактически язык можно сделать таким, каким ты хочешь его видеть, так? Захотел, назвал операцию while — "while", а захотел — "cyclew", правильно?
Неправильно. В C++ как раз есть возможность переименовать while в cyclew — #define cyclew while. А в Nemerle есть возможность лишь добавить операцию cyclew, причем возможность достаточно ограниченная и неудобная, чтобы этого не делать на каждом шагу. Макросы компилируются и кладутся в сборки, затем эти сборки нужно явно подключить при компиляции. Да еще разумные люди кладут макросы в пространства имен, которые тоже нужно подключить перед использованием. Но конечно ничто никогда не заменит нормального человеческого здравомыслия — здравомыслящему человеку не прийдет идея создавать операции аналогичную while, да еще с таким причудливым названием.

Макросы дали большое преимущество самим разработчикам языка и реализованные на макросах конструкции языка в разы удобнее, чем похожие "полноценные", вшитые в компилятор, конструкции в C#. Тот же foreach например поддерживает вывод типов, паттерн-мэтчинг, диапазоны(foreach(i in [1..100])), а все благодаря мощному core языку и реализации на макросах(реализовать некую синтаксическую конструкцию на макросах это зачастую в десятки раз проще, чем вшить в компилятор, а результат как можно увидеть на примере конструкций Nemerle получается лучше в разы).

А конечном пользователям Nemerle(в данном случае разработчикам) макросы больше помогут не в задачах блошиного уровня, типа операции cyclew, а в задачах серьезной генерации кода, основанной на информации на типах(эдакий compile-time reflection) или другой информации нетривиального характера(типа описания грамматики или некоего DSL).

FR>Как вы считаете, хорошо ли давать подобную свободу программисту? Да, это действительно удобно. Это действительно похоже на некое "метапрограммирование".
Никакой свободы нет. Ощущение свободы покидает уже на первой неделе знакомства с макросами Nemerle. Есть разумный компромисс между свободой, удобством и прагматичностью. Nemerle это один из наиболее удобных и прагматичных инструментов для метапрограммирования. Наиболее удобные и свободные инструменты метапрограммирования можно(теоретически, потому что это обычно там мало кому нужно) сделать только в динамически-типизированных языках(а Nemerle к таким не относится), но за такую свободу действительно приходится очень дорого платить.

FR>Но хорошо ли это для качества кода? Для командной разработки программных продуктов? Сколько страниц будут занимать правила написания кода программы для какого-либо проекта в сравнении с аналогичными для, скажем, C#? Насколько возрастут затраты на написание подобного документа и насколько просто будет потом другим пользователям (если это, например, opensource проект) разбираться в написанном коде не прочитав этот талмуд.
Nemerle это opensource проект, с более чем десятком контрибуторов. Вот Oyster например после очень непродолжительного изучения Nemerle смог найти и пофиксить недоделку в компиляторе(добавив фичу в парсер и макро-движок). Сейчас несколько человек с rsdn успешно делают проект интеграции с Visual Studio, использующий сам компилятор в качестве библиотеки. Есть и другие примеры(в том числе и основанные на моем личном опыте) того, что после очень непродолжительного изучения Nemerle, люди спокойно ориентируются в коде его компилятора, в том числе правят его и используют его api(в макросах). И это при явном недостатке документации. По-моему это говорит о многом.

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

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

FR>Код, написанный на языке с простым и понятным синтаксисом, гораздо проще поддерживать и сопровождать, как мне кажется.

Да, черт побери! Сто раз ДА! И как раз именно код Nemerle в большинстве случаев будет проще и понятнее.

НО! Для этого нужно изучить особенности языка. Если ты из императивного мира и ранее выдел только алголоподобные объектно-ориентированные языки, такие как Дельфи, С++, Ява, Шарп, Руби или Питон, то тебе прийдется понять и принять несколько концеций которых практически нет в этих языка или которые в нем редко применимы и мало значемы.

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

Из конкурентов я вижу только Эрланг и Лисп. У первого есть незаурядные идеи и так нужная в этом мире простота. У второго есть почти все что есть у Nemerle, но все же он глубокой ... из-за многих причин (от отсуствия синтаксиса, до тонких внутренних проблем и невменяемых поклонников).

Забавно, что на Nemerle ополчились со всех сторон.
Те кто пришел из императивного мира и пока (или вообще) не может оценить всех его прелестей и выразительности ополчились на него и пытаются всеми силами найти в нем проблемы. Зачем? Не знаю. Им все время мерещится, что Nemerle это так называемая реинкарнация серебренной пули, то есть панацея. Но Nemerle не панацея. Nemerle — это следующая ступень эволюции языков программирования. Возможно тупиковая как Лисп. Но мне почему-то кажется, что Nemerle будет жить если конечно МС не решит сделать такой же язык но другой (с). Но если МС это сделает, то мы получим Nemerle от МС. А это сделает из него бестселлер. Что тоже не плохо.
Другая группа это те кто практически не пересекался с миром Явы или дотнета, но имел неосторожность глубоко погрузиться (порой до полного фанатизма) функциональный мир. В этом мире почему-то экстремизм вообще практически является нормой, а уж такие раздражители как императивно-обектно-ориентированно-фиункционально-метопрограммный язык вызвает у них вообще странную реакцию. Один пытается объяснить, что у него система типов не той системы (с). Другой, что макросы не позволяют с легкостью прострелить себе остатки мозга через пятку. Третие сетуют что он вообще не функциональный так как в нем есть присвоения переменных забывая, что процентах в 80% признанных ФЯ это дело тоже есть.
В общем, настоящая политика! Ну, да тем лучше. Все новое должно пройти через тернии чтобы выбиться в звезды. А мне почему-то кажется, что Nemerle это звезда, которую пока по недомыслию многие принимают за назойливый фонарик маячащий в дали.

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

VD>Другой, что макросы не позволяют с легкостью прострелить себе остатки мозга через пятку.

Под столом

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

VD>НО! Для этого нужно изучить особенности языка. Если ты из императивного мира и ранее выдел только алголоподобные объектно-ориентированные языки, такие как Дельфи, С++, Ява, Шарп, Руби или Питон,

Руби и питон попрошу исключить из списка

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

FR>Руби и питон попрошу исключить из списка

С чего бы это?

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

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

FR>>Руби и питон попрошу исключить из списка

VD>С чего бы это?

С того что там легко писать в функциональном стиле, и плюс есть метапрограммирование.

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

FR>>>Руби и питон попрошу исключить из списка

VD>>С чего бы это?

FR>С того что там легко писать в функциональном стиле, и плюс есть метапрограммирование.

Хм. Это привносит в Руби паттерн-матчинг и алгебраические типы? Нет? Странно... Но раз нет, то как Руби или Питон помогут в освоении этих понятий?

Да и метапрограммирование там не то что в Немерле. Так что они на своем месте.

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

VD>Хм. Это привносит в Руби паттерн-матчинг и алгебраические типы? Нет? Странно... Но раз нет, то как Руби или Питон помогут в освоении этих понятий?

Паттерн матчинг вещь практически интуитивно понятная для императивного программиста и не является основным понятием в функциональном программировании (как тут выражаются чистый сахар ).

VD>Да и метапрограммирование там не то что в Немерле. Так что они на своем месте.

Оно там есть и в отличии от например С++ с человеческим лицом, а освоить еще один способ того что уже знаешь и используешь гораздо проще (психика не портится ) чем осваивать с нуля.

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

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

VD>>Хм. Это привносит в Руби паттерн-матчинг и алгебраические типы? Нет? Странно... Но раз нет, то как Руби или Питон помогут в освоении этих понятий?

FR>Паттерн матчинг вещь практически интуитивно понятная для императивного программиста

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

FR>и не является основным понятием в функциональном программировании (как тут выражаются чистый сахар ).

А кто-то утверждал обраное? Это был не я.
Я говорил о другом. Я говорил о бэкграунде императивных языков и о всоприятии новых возможностей.

VD>>Да и метапрограммирование там не то что в Немерле. Так что они на своем месте.

FR>Оно там есть и в отличии от например С++ с человеческим лицом,

Я бы сказал с более человеческим. По крайней мере некоторые текстуальные гримассы Руби меня удручили.

FR> а освоить еще один способ того что уже знаешь и используешь гораздо проще (психика не портится ) чем осваивать с нуля.

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